Showing posts with label dual. Show all posts
Showing posts with label dual. Show all posts

Tuesday, March 20, 2012

Query Performance

Hi all,

I′m using SQL Server 2000 in the Windows 2003 Server with 2GB RAM
and 2 dual core processors.
There is an application that access the SQL Server.
Several queries are with problems of performance.
I cannot change these queries ′cause the application
was made by other IT company.

[code]
SELECT * FROM SE1010 SE1
WHERE E1_FILIAL = ' '
AND D_E_L_E_T_ <> '*'
AND E1_CLIENTE BETWEEN ' ' AND 'ZZZZZZ'
AND E1_PREFIXO BETWEEN ' ' AND 'ZZZ'
AND E1_NUM BETWEEN ' ' AND 'ZZZZZZ'
AND E1_PORTADO BETWEEN ' ' AND 'ZZZ'
AND E1_VENCREA BETWEEN '20010101' AND '20070228'
AND (E1_MULTNAT = '1' OR (E1_NATUREZ BETWEEN ' ' AND 'ZZZZZZZZZZ'))
AND E1_EMISSAO BETWEEN '20010101' AND '20070228'
AND E1_LOJA BETWEEN ' ' AND 'ZZ'
AND E1_EMISSAO <= '20070301'
AND ((E1_EMIS1 BETWEEN '20060101' AND '20070228')
OR E1_EMISSAO BETWEEN '20060101' AND '20070228')
ORDER BY E1_FILIAL,E1_PREFIXO,E1_NUM,E1_PARCELA,E1_TIPO

The execution plan is:

|--Sort(ORDER BY:([SE1].[E1_PREFIXO] ASC, [SE1].[E1_NUM] ASC,
[SE1].[E1_PARCELA] ASC, [SE1].[E1_TIPO] ASC))
|--Filter(WHERE:((((([SE1].[E1_EMISSAO]>='20010101'
AND [SE1].[E1_EMISSAO]<='20070228') AND [SE1].[E1_LOJA]>=' ')
AND [SE1].[E1_LOJA]<='ZZ') AND [SE1].[E1_EMISSAO]<='20070301')
AND (([SE1].[E1_EMIS1]>='20060101' AND
[SE1].[E1_EMIS1]<='20070228') OR
|--Clustered Index Scan(OBJECT:([DADOSADV].[dbo].[SE1010].[SE1010_PK]
AS [SE1]), WHERE:(((((((((((([SE1].[E1_FILIAL]=' '
AND [SE1].[D_E_L_E_T_]<>'*') AND [SE1].[E1_CLIENTE]>=' ')
AND [SE1].[E1_CLIENTE]<='ZZZZZZ') AND [SE1].[E1_PREFIXO]>=''

[/code]

I′ve created index for the columns that are used by where clause
and I′ve performed the DBCC INDEXDEFRAG and DBREINDEX, but after I′ve performed
theses functions, the performance fell.

What can I do to improve query performance?

thanks!!!!Moving to engine forum.

Monday, March 12, 2012

Query parallelism/ACCESS and DUAL PROCESSORS?

We have a large operation - SQL server with lots of users attaching via VB programs. Most operations to the database occur within stored procedures.
The SQL server is also used by an ACCESS front end for another application.
The ACCESS queries started getting this error:
Server: Msg 8650, Level 13, State 127, Line 1
Intra-query parallelism caused your server command (process ID #79) to deadlock. Rerun the query without intra-query parallelism by using the query hint option (maxdop 1).
The ACCESS developer found some KB articles indicating that turning off the DUAL PROCESSOR would fix the problem.
We have concerns about how the rest of the server usage will react to turning off the DUAL PROCESSOR option.
Anyone have experience with this type of problem?
Usually the work-around states that you can disable the use of multiple
processors at the server level OR you can disable parallelism for the
specific query causing the problem. Assuming that you can identify the
specific queries and can modify them, then it is far better to change the
queries. Otherwise you lose the benefit of multiple processors which can be
very significant!
"Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
news:08A84C96-7E31-4937-A419-4EBB06E10082@.microsoft.com...
> We have a large operation - SQL server with lots of users attaching via VB
programs. Most operations to the database occur within stored procedures.
> The SQL server is also used by an ACCESS front end for another
application.
> The ACCESS queries started getting this error:
> Server: Msg 8650, Level 13, State 127, Line 1
> Intra-query parallelism caused your server command (process ID #79) to
deadlock. Rerun the query without intra-query parallelism by using the query
hint option (maxdop 1).
>
> The ACCESS developer found some KB articles indicating that turning off
the DUAL PROCESSOR would fix the problem.
> We have concerns about how the rest of the server usage will react to
turning off the DUAL PROCESSOR option.
> Anyone have experience with this type of problem?
|||get rid of the access clients.
Greg Jackson
PDX, Oregon

Query parallelism/ACCESS and DUAL PROCESSORS?

We have a large operation - SQL server with lots of users attaching via VB p
rograms. Most operations to the database occur within stored procedures.
The SQL server is also used by an ACCESS front end for another application.
The ACCESS queries started getting this error:
Server: Msg 8650, Level 13, State 127, Line 1
Intra-query parallelism caused your server command (process ID #79) to deadl
ock. Rerun the query without intra-query parallelism by using the query hint
option (maxdop 1).
The ACCESS developer found some KB articles indicating that turning off the
DUAL PROCESSOR would fix the problem.
We have concerns about how the rest of the server usage will react to turnin
g off the DUAL PROCESSOR option.
Anyone have experience with this type of problem?Usually the work-around states that you can disable the use of multiple
processors at the server level OR you can disable parallelism for the
specific query causing the problem. Assuming that you can identify the
specific queries and can modify them, then it is far better to change the
queries. Otherwise you lose the benefit of multiple processors which can be
very significant!
"Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
news:08A84C96-7E31-4937-A419-4EBB06E10082@.microsoft.com...
> We have a large operation - SQL server with lots of users attaching via VB
programs. Most operations to the database occur within stored procedures.
> The SQL server is also used by an ACCESS front end for another
application.
> The ACCESS queries started getting this error:
> Server: Msg 8650, Level 13, State 127, Line 1
> Intra-query parallelism caused your server command (process ID #79) to
deadlock. Rerun the query without intra-query parallelism by using the query
hint option (maxdop 1).
>
> The ACCESS developer found some KB articles indicating that turning off
the DUAL PROCESSOR would fix the problem.
> We have concerns about how the rest of the server usage will react to
turning off the DUAL PROCESSOR option.
> Anyone have experience with this type of problem?|||get rid of the access clients.
Greg Jackson
PDX, Oregon