Parallel Plans

Hi,
Our production server is a Compaq Proliant with 2 CPU. How can I determine
that my queries benefit from having 2 CPU? Are parallel plans automatically
created our I must configure server options?
Any help would be greatly appreciated.
LeilaYou can check if your server is set to use parallel query plans on the
processor tab of the server properties in Enterprise Manager.
You can check if any queries with a parallel plan are executed by tracing
the DegreeOfParallelism event with SQL Profiler. See the topic "Degree of
Parallelism" in Books Online for details.
--
Jacco Schalkwijk
SQL Server MVP
"Leila" <Leilas@.hotpop.com> wrote in message
news:OmMhaHYzEHA.1192@.tk2msftngp13.phx.gbl...
> Hi,
> Our production server is a Compaq Proliant with 2 CPU. How can I determine
> that my queries benefit from having 2 CPU? Are parallel plans
> automatically
> created our I must configure server options?
> Any help would be greatly appreciated.
> Leila
>|||If you are using the database with more than one user, then you are
likely to benefit from the extra CPU even if no parallellism is chosen,
because in that case the workload can be divided over 2 CPU's instead of
just the 1.
Gert-Jan
Leila wrote:
> Hi,
> Our production server is a Compaq Proliant with 2 CPU. How can I determine
> that my queries benefit from having 2 CPU? Are parallel plans automatically
> created our I must configure server options?
> Any help would be greatly appreciated.
> Leilasql

Page SPlits and finding out Record size and Page Info

I am trying to determine if pages in a table are close to full and likely to
page split.
Using DBCC SHOWCONTIG ( table) WITH TABLERESULTS, ALL_INDEXES, ALL_LEVELS
I get MinimumRecordSize, MaximumRecordSize only for the indexes How can I
get this information on the data itself? If an update is going to change a
the average record size by increasing it 15 bytes, and the avg is 500 bytes,
I would assume that there are on average 8 records per page and the increase
would push one record out, or 1 in 8, so a 25 million record table would
encounter 3,125,000 page splits. With a clustered index, I believe we have
been experiencing some bad performance issues and turning off clustering on
the index and adjusting the free space per page, hopefully will help with
the updates.
Is there anyway to reorganize the data so that it is only using say 60% of
the file pages so that updates are less likely to page split?I may have fired too soon.
My response refers to Index Organization. Not data itself.
Cheers,
GAJ