|
Should Sybase v10.0.1.3960 running on VMware still be able to use parallel table scans ? I have some fairly simple SQL that performs a couple of joins from a small customer table to a reasonable head table then onto quite a large lines table. Some of the where clause is using fields that aren't in the index, but on my development machine it takes a few seconds to run, on our live servers it takes even less time to run, however on our test system (which uses Vmware) it runs for at least 15mins before I get bored and kill it. I've checked the plans on all the machines and the test server doesn't try to use parallel table scans but the others do. I've not had much experience of VMware or parallel table scans (I didn't even know about them until I checked the plan), Is there anything obvious I should be looking into ? |
|
Several possibilities jump to mind; seeing the graphical plan would help. Some things to consider:
2
It sounds like the short answer to the first question on the first line is yes, the query engine is able to use parallel table scans under VMWare. 'drop statistics' on the tables we were using worked for our test server. Our test db was running a backup of the live db with the same startup options as the live server except for dbeng instead of dbsrv, vmware had 2 cores available. At a guess maybe after moving the db from one server to another it didn't have enough time to generate some meaningful stats ? 3
@Daz: dbeng will only use one CPU. See http://sqlanywhere-forum.sap.com/questions/1084/what-are-all-the-differences-between-the-personal-and-network-database-servers Comment Text Removed
I did wonder why the plan was only using one table scan now rather than the 2 parallel ones used by the live server, the speed increase 15 mins down to 2 seconds must have come from the rest of the plan changing after the statistics changed. I just assumed (wrongly) that it was the parallel part that was making it go so much faster on the live. Wonder what the reasoning for dbeng only using 1 cpu is? |
