Tenho o seguinte select a correr numa maquina virtual com 10GB de memoria 2 processador estando disponvivel para
a maquina virtual com o sql 4 nucleos de processador.
Ao correr a seguinte rotina: "select docnome,adoc,data from ml where dilno not in (select dilno from ol where plano=1)"
O processador atinge os 100% bloqueando todo o sistema.
A mesma rotina a correr num computador com 1 processador e 4 GB de memoria, estando a base de dados e o sql configurados da mesma maneira o processador em termos de performance nem se quer se mexe.
Já recriei index e fiz update estatistics, coloquei nas opções da base de dados sql2008(100) e continua na mesma.
Fidalgo
Esse teste só será válido se a base for exatamente a mesma com as mesmas quantidades de registros (pressupondo que os índices também já são os mesmos). Se isso não for verdadeiro o teste não é válido. Na hipótese dessas condições serem atendidas, só mesmo vendo o plano de execução para entender o que aconteceu.
De qualquer forma, sugiro abandonar o trágico NOT IN. Maiores detalhes em:
Já percebi o problema, utilizei plano de execução e verifique que a query está a fazer loop e este lop deve-se ao facto de a instrução "select dilno from ol where plano=1" está errado visto que o campo dino passou a chamar-se dilnoplanoFidalgo
Já utilizei nolock e o problema é o mesmo os index que utilizo são: na tabela ml: dilno ascending origem ascending mes ascending Criei ainda este index CREATE NONCLUSTERED INDEX [_dta_index_ml_7_1517586282__K3_4_5_6] ON [dbo].[ml] ( [dilno] ASC ) INCLUDE ( [docnome], [adoc], [data]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
Esse teste só será válido se a base for exatamente a mesma com as mesmas quantidades de registros (pressupondo que os índices também já são os mesmos). Se isso não for verdadeiro o teste não é válido. Na hipótese dessas condições serem atendidas, só mesmo vendo o plano de execução para entender o que aconteceu.
De qualquer forma, sugiro abandonar o trágico NOT IN. Maiores detalhes em:
Já percebi o problema, utilizei plano de execução e verifique que a query está a fazer loop e este lop deve-se ao facto de a instrução "select dilno from ol where plano=1" está errado visto que o campo dino passou a chamar-se dilnoplanoFidalgo
