none
Aumento no tempo de execução dos jobs ao migrar do ambiente de 32 para 64 bits (Windows e SQL SERVER) RRS feed

  • Pergunta

  • Prezados,

    Os servidores SQL SERVER 2005 com que trabalho estavam com Windows Server 2003 32 bits e SQL SERVER 2005 também 32 bits, claro.

    Li vários "papers" sobre as vantagens que o SQL SERVER poderia usufruir, em termos de performance e gerenciamento memória, em um ambiente de 64 bits. Após muita leitura sobre o assunto, pesquisando na Internet, daí resolvemos migrar os servidores SQL SERVER para o ambiente de 64 bits, sendo o SO o Windows Server 2008 R2 SP 1 e o SGBD o SQL SERVER 2005 64 bits.

    Após isso, verifiquei uma coisa estranha : os jobs agendados no Agent, neste novo ambiente 64 bits, passou a ter o tempo de execução consideravelmente maior em relação ao ambiente de 32 bits (pude verificar isso através da opção "View History" de cada job, nos dois ambientes, pois o de 32 bits ainda está ativo).

    Adianto que os jobs são exatamente iguais nos dois ambientes (lembre-se que um ambiente é cópia do outro em termos de base de dados, jobs etc) e que executam sempre no mesmo horário.

    A maioria desses jobs são execução de pacotes DTS que foram migrados para o Integration Services e alguns, por possuir o objeto "Execute DTS 2000 Package Task" no seu "Control Flow", só executam com job do tipo "Operating system (CmdExec)", através do comando "Dtexec", no modo 32 bits, pois este objeto é incompatível com o modo 64 bits, enquanto que estes mesmos jobs, no ambiente de 32 bits, são do tipo "Sql Server Integrations Services Package", visto que neste ambiente esta limitação deixa de existir.

    Seria esse o motivo para fazer com que no ambiente de 64 bits os jobs aumentassem tanto assim seus tempos de execução ? Pude perceber que, na média, cada job acresceu 50% no seu tempo de execução, sendo que alguns quase dobrou de tempo.

    São jobs que rodam de madrugada, por isso fiquei meio alarmado, pois em ambos os ambientes a realidade é igual, ou seja, o servidor praticamente sem carga, quase que dedicado à execução destes jobs.

    Agradeço muito qualquer esclarecimento que os senhores possam me fazer neste sentido.

    Obrigado,

    José Luiz

    PS : Vale lembrar que todos os jobs tiveram seu tempo de execução aumentado no ambiente de 64 bits, até mesmo os que não possuem o objeto "Execute DTS 2000 Package Task" no seu "Control Flow" e executam, nos dois ambientes, com jobs do mesmo tipo, ou seja, do tipo "Sql Server Integrations Services Package".


    segunda-feira, 25 de julho de 2011 21:23

Todas as Respostas

  • Jose,

     

    Este é um problema muito recorrente aqui no forum, depois da migração, é quase obrigatorio a execução de update nas estatisticas com full scan, realize este processo em seu ambiente e veja se ha melhoras.


    Fabrizzio A. Caputo
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCTS SQL Server 2008
    Developer Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    • Sugerido como Resposta Iniciante em SQL terça-feira, 26 de julho de 2011 19:02
    terça-feira, 26 de julho de 2011 13:08
    Moderador
  • Apenas complementando o que o Fabricio disse, em alguns ambientes quando há mudança de hardware é necessário rodar as atualizações das estastísticas, bem como avaliar os planos de execução e a alocação de processamento/memória ao SQL Server. Em um cliente conseguimos melhorar em 40% o tempo de execução de algumas tarefas pelo Agent realizando a configuração com os novos hardwares instalados.
    terça-feira, 26 de julho de 2011 19:05
  • Fabrizzio,

    Obrigado pela resposta.

    Pois é... Aqui é que está o problema. Eu já rodei o Update nas estatísticas, em todas as bases de dados do servidor, através de um "Maintenance Plan" criado por mim, contendo o objeto "Update Statistic Task",  com a opção "Update" como  "All existing statistics" e a opção "Scan type" como "Full scan", mas mesmo assim, após a execução deste "Maintenance Plan", ainda assim os tempos de execução dos jobs do novo servidor (em ambiente 64 bits) está bem maior do que no antigo servidor (em ambiente 32 bits).

    Sinceramente não sei o porquê disso.

    José Luiz

    quarta-feira, 27 de julho de 2011 19:48
  • Jose,

     

    Existe alguma tarefa schedulada de rebuild dos indices em seu ambiente?


    Fabrizzio A. Caputo
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCTS SQL Server 2008
    Developer Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    quarta-feira, 27 de julho de 2011 19:51
    Moderador
  • Olá, obrigado pela complementação na resposta do Fabrizzio, mas até onde sei, com o Windows Server 2008 R2 a alocação de recursos, como exemplo, a memória é muito mais otimizado e sem limitação no tamanho para o SQL SERVER.

    Por isso, recursos do tipo AWE e PAE não são precisos serem configurados manualmente como eu fazia no ambiente do SQL SERVER 32 bits, pois o Windows 2008 R2 irá gerenciar isso e com possibilidade de uso de toda a memória disponível (uma vez que o limite da quantidade de memória que pode ser gerenciado pelo W2K8 é absurda !).

    A única coisa que fiz, neste caso, foi habilitar a policy "Lock pages in memory" para a chave de domínio que "starta" o serviço do SQL SERVER.

    Se há outra configuração que há que ser feita, em relação ao uso da memória, num ambiente 64 bits conforme o que citei, eu infelizmente desconheço.

    quarta-feira, 27 de julho de 2011 19:58
  • Jose,

     

    Bom, em relação a alocação de memoria, existe sim uma limitação, se não me engano a limitação para a versão enterprise do SQL Server 2008R2 é 128 GB (Ou algo assim, para servidores com necessidade de mais memoria é necessario o SQL Server 2008R2 DataCenter).

    Sim, o AWE é para gerenciamento de 32 enxergar mais de 4GB de memoria, houve um topico bem recente sobre isso, e a conclusão geral, foi que não ha um ganho garantido na ativação do mesmo, teoricamente o mesmo não precisa ser realmente ativado.

     

    Em relação a minha ultima pergunta, quis dizer em relação aos indices do proprio SQL, após a migração, seria interessante o rebuild dos mesmos, a sintaxe para isso é:

    ALTER INDEX IndexName ON TableName REBUILD

    Recomendo que não só após a migração, mas que exista uma constancia na execução deste comando.

    Teoricamente no meio da operalção de rebuild, as estatisticas ja são atualizadas, mas é bom assim que terminar o processo, rodar outro update with fullscan.

    Outra coisa, a unica coisa que foi alterada em seu ambiente foi o Sistema operacional? houve mudança de hardware por exemplo? 


    Fabrizzio A. Caputo
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCTS SQL Server 2008
    Developer Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    quarta-feira, 27 de julho de 2011 20:04
    Moderador
  • Fabrizzio,

    Existe sim... Aliás, neste "Maintenance Plan", que é executado semanalmente no meu servidor, existem três objetos, na seguinte ordem :

    1) Rebuild Index Task
    2) Update Statistic Task
    3) Check Database Integrity Task


    Ou seja, o procedimento de "Rebuild" nos índices de todas as bases de dados da instância, precede imediatamente ao "update" das estatísticas.

    Será que tem alguma coisa errada nesta precedência ?

    quarta-feira, 27 de julho de 2011 21:38
  • Fabrizzio,

    Sobre o limite de memória para o SQL SERVER 2005 64 bits,tenho várias referências de que gerencia uma quantidade bem grande (acima desta citada por você). Veja o link abaixo :

    http://www.teratrax.com/articles/sql_server_64_bit.html

    Perceba no ítem "Memory addressing with 64-bit vs. AWE" o seguinte trecho :

    "In contrast, SQL Server 2005 (64-bit) makes memory available to all database processes and operations. Using the 64-bit version on either IA64 or x64 hardware, a SQL Server instance can address up to 1 terabyte of memory; the current maximum amount of physical memory supported by Windows Server 2003 SP1. This memory is available to all components of SQL Server, and to all operations within the database engine."

    Ou seja, SQL SERVER 2005 64 bits gerencia até 1 TB de memória, isso no Windows Server 2003, por limitação do sistema operacional. No Windows Server 2008 R2 o limite é absurdo, por isso que citei como "sem limite". Além disso, essa memória pode ser "cacheada" por todos os componentes do SQL SERVER 2005 64 bits, ao passo que no SQL SERVER 2005 32 bits, com uso do AWE, a memória só faz cache de dados e "execution plan", indexações, joins, classificações etc, tudo é passível de "swap".

    No SQL SERVER 2008 citado por você, o link abaixo fala em 8 TB de memória na arquitetura x64 :

    http://msdn.microsoft.com/pt-br/library/ms187499.aspx

    --------------------------------

    Quanto ao REBUILD, não sei se me fiz entender na minha resposta, mas foi exatamente isso que eu falei. No meu "Maintenance Plan" que é executado semanalmente via job (aos domingos de madrugada), existe um objeto "Rebuild Index Task", que faz a reindexação de todos os índices de todas as bases de dados. O comando gerado é exatamente esse que você citou, para cada índice de cada tabela de todos as bases de dados.
    Portanto, todas as bases de dados já passaram por REBUIL de índices, mas mesmo assim a diferença de tempos de execução dos jobs se mantém.
    Realmente só mudei o ambiente (SO + SQL) de 32 para 64 bits. Quanto aos hardwares, os dois são exatamente a mesma configuração : Dual-Core AMD Opteron Processador 8222 SE, 3.01 GHz e 36 GB de memória.

    Continuo sem entender o porquê do aumento considerável no tempo de execução dos jobs.

    Caso tenha mais alguma pergunta, fique a vontade.

    Obrigado pela atenção mais umavez.



    quarta-feira, 27 de julho de 2011 23:40