SQL Q+AComo evitar reinicializações, instalação de várias atualizações e muito mais

Editado por Nancy Michell

Como evitar reinicializações

P Como posso limitar o número de reinicializações ao aplicar hotfixes e o mesmo para o SQL Server e até para o sistema operacional do servidor em geral?

R Antes de mais nada, você deve estar interessado em saber que a maioria das reinicializações após a instalação não são codificadas no instalador. Normalmente, elas são o resultado de arquivos bloqueados. Isso significa que o instalador está tentando atualizar arquivos que estão atualmente em uso (bloqueados) por algum outro aplicativo ou pelo sistema operacional. Existe uma abordagem simples para eliminar essas reinicializações: verificar se nenhum processo está usando os arquivos em questão. Como fazer isso?

O primeiro passo é determinar os arquivos específicos que estavam em uso e foram bloqueados durante a instalação. O modo mais fácil é examiná-los no registro, em HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. Verificar essa chave do registro serve a dois propósitos: confirma que a solicitação de reinicialização foi de fato causada por arquivos bloqueados e indica quais arquivos estavam bloqueados. Se fizer essa verificação após a instalação, mas antes da reinicialização, você poderá descobrir o que causou a necessidade de reinicialização e tomar medidas para eliminá-la nas instalações futuras.

Dois tipos de entradas podem ser encontrados. Se o arquivo estava bloqueado para leitura, você observará uma entrada de uma linha por arquivo, o que significa que o arquivo atualizado já está no disco, mas é preciso limpar a cópia temporária que ainda está em uso. Se o arquivo estava bloqueado para gravação, você notará uma entrada de duas linhas por arquivo, o que significa que a atualização ainda não aconteceu, o aplicativo está em estado desconhecido e não deve ser usado. É, literalmente, como parar no meio da instalação. Nesse caso, uma linha indica o arquivo real e a outra aponta para um arquivo temporário (que se tornará o arquivo real na reinicialização).

A próxima etapa depende de muitos fatores, mas a idéia é identificar qual software está usando os arquivos bloqueados. Use verificadores de dependência, se puder, ou o banco de dados DLL HELP da MSDN® (consulte support.microsoft.com/kb/815065).

Se o software identificado tiver um serviço, interrompa o serviço manualmente e, em seguida, teste de novo. Se for um aplicativo, feche-o e tente outra vez. Às vezes, vários aplicativos usam um mesmo arquivo e é necessário interromper todos eles.

O resultado desses testes (em seu ambiente de testes) é uma lista de aplicativos e serviços a serem interrompidos no ambiente de produção, antes da instalação. Logo, o ambiente de produção não precisará de uma reinicialização, pois nenhum software manterá bloqueios em arquivos a serem instalados pelo instalador. Lembre-se, é claro, de reiniciar cada um deles quando a instalação estiver concluída.

O lado bom disso tudo é que os bloqueios geralmente não variam muito. Assim, se você descobrir uma vez esse padrão em seus sistemas, isso provavelmente evitará muitas reinicializações durante o tempo de vida de seu sistema.

Há ainda um outro truque que vale a pena mencionar. Pode ser que você tenha várias versões do SQL Server™ ou de um outro produto instaladas lado a lado que podem ter níveis de versão diferentes. Atualize primeiro, sempre, a versão mais recente. Há boas chances de que a atualização substitua tudo pelas últimas versões, de modo que todas as outras instâncias não se importarão em nada com bloqueios. Por exemplo, se você tiver três instâncias do SQL Server 2000 SP3, a primeira que você atualizar para SP4 atualizará o arquivo MSXML3.dll e precisará de reinicialização. Digamos que você faça a reinicialização nesse instante. Então, você poderá atualizar as próximas duas instâncias para SP4 sem ter que fazer a reinicialização, porque o arquivo MSXML3.dll atualizado já está presente. O mesmo vale para a atualização de qualquer instância do SQL Server 2005 antes de instâncias do SQL Server 2000, e do SQL Server 2000 antes do SQL Server 7.0. Trata-se de uma estratégia geral de minimização de reinicializações que realmente funciona.

Olhando para o quadro geral, as equipes de desenvolvimento da Microsoft têm tido muito trabalho para eliminar ou limitar o número de reinicializações em diversos cenários. Como se trata da coluna de Perguntas e Respostas sobre SQL, tomemos o SQL Server como exemplo.

No SQL Server 2005, a equipe do SQL Server dividiu o Microsoft® Data Access Components (MDAC) necessário para o SQL Server em SQLNCLI (arquivos novos), em vez de atualizar o próprio MDAC, e recolocou o MDAC em banda com o SO. Como isso pode nos ajudar? Bem, o próprio sistema operacional Windows® usa MDAC e mantém esses arquivos bloqueados. É por isso que a maioria dos pacotes de serviços do SQL Server, assim como outros pacotes, sempre necessitaram de reinicialização. Agora, o SQL Server pode atualizar sua versão do MDAC sem tocar nos arquivos MDAC em uso pelo SO, de modo que não há necessidade de reiniciliazação.

Além disso, agora existe um verificador de dependência e uma pausa dentro da instalação do SQL Server 2005 SP1. Isso mostra o que está bloqueado e o que provavelmente o bloqueou, dando a você a chance, no lugar e tempo certos, de interromper o que quer que esteja provocando o bloqueio e continuar a instalação sem reinicializar. Isso significa que você pode se divertir com isso em tempo real, sem precisar de um laboratório de testes. Obviamente, sempre é possível simplesmente continuar e fazer a reinicialização, se preferir ou se a execução estiver no modo autônomo. Note como isso facilita descobrir quem está bloqueando seus arquivos!

Além disso, a tecnologia do Microsoft Installer também processa as PFRs (PendingFileRenameOperations) muito melhor. Você deve se recordar de que a instalação do SQL Server 2000 era bloqueada quando algum arquivo aparecia na chave de registro que já discutimos. A instalação do SQL Server 2005 é inteligente o bastante para bloquear somente os arquivos que pertencerem ao SQL Server (o que significa que pode haver um conflito) e, mesmo nesses casos, é possível alcançar a chave PFR e atualizá-la diretamente, sem necessidade de reinicialização. Essa tecnologia está contida em algum nível no MSI e no update.exe, que são os instaladores padrão atuais da Microsoft usados para realizar todas as atualizações.

Quais são algumas das descobertas conhecidas que causam reinicializações? O MSXML3.dll é uma das maiores. Esse arquivo é sempre bloqueado pelo serviço SVCHost do Windows, de modo que tudo que incluir esse serviço necessitará de reinicialização. E ele também está na maioria das pilhas de MDAC (mdac_typ.exe). Felizmente, o MDAC está "em banda" no Windows Server® 2003 e no Windows XP SP2 e posteriores. A equipe de desenvolvimento do SQL Server fez um ótimo trabalho ao dividir o msxmlsql.dll, de modo que as atualizações do SQL Server não provocarão reinicialização, muito embora você possa observar isso acontecer de vez em quando. Não há nada a fazer nesse caso - não é possível desligar o SVCHost e continuar a executar atualizações.

Além disso, os pacotes do update.exe têm algumas peculiaridades no que diz respeito ao processo de desinstalação. Se você desinstalar um deles, ele colocará um bloqueio (fora das chaves PFR, é claro) nos arquivos in-loco do instalador. Isso evita que outros pacotes do update.exe possam ser executados até que seja feita uma reinicialização para limpar o bloqueio. Tudo o que você realmente pode fazer é ter consciência disso e planejar a reinicialização depois das desinstalações de hotfix que fizer.

Intermitência é uma outra questão. Nem todos os programas trabalham sobre um arquivo 100 por cento do tempo. Na verdade, a maior parte do uso de DLLs compartilhadas é pontual, o que significa que outros programas as acessam apenas de acordo com a necessidade, dependendo de suas próprias tarefas de carregamento e caminhos de código. Isso significa que você poderia fazer um teste 10 vezes e não ver arquivos bloqueados, mas topar com um na implantação da produção. Não há receita mágica, infelizmente. Apenas crie seu ambiente de testes da forma mais semelhante possível a seu ambiente de produção, incluindo testes suficientes de carregamento (sempre uma boa meta) e execução para expor essas permutas.

Os pacotes de serviços e as atualizações de SO provocarão reinicializações. Observe ainda que nas versões de nível menor (Windows 2000, Windows XP e anteriores), a instalação não termina até que a reinicialização seja concluída, mesmo que a chave de registro pendingfilerenameoperations esteja vazia. Há exceções em operações de registro de pacotes que podem ser executadas para instalar código durante a reinicialização. Elas não fazem parte nem mesmo da instalação de pacotes de serviços, mas são comandos incorporados em seu sistema operacional atual, disparados pelos cenários de atualização, para permitir que certos trechos de código em uso sobrevivam a elas.

Finalmente, a chave PFR não faz verificações de versão de arquivo, nem impõe ordem através de serialização. Isso significa que ela aciona as substituições de arquivos na ordem em que estão listadas. Mas a ordem em que são aplicadas ao disco rígido já se provou ser a última para terminar (e não a primeira para começar). Isso faz sentido, mas significa que ter duas cópias do mesmo arquivo no mesmo caminho, cada um apontando para versões diferentes, produzirá um resultado aleatório após a reinicialização. Se você topar com isso, trate de corrigi-lo. Se estiver inseguro, basta executar ambos os instaladores novamente após a reinicialização. Se obtiver os arquivos certos, não terá problema. Se obtiver os errados, seja qual for o pacote que tiver o certo, agora, você fará a correção. Francamente, isso é mais rápido e mais seguro do que tentar imaginar qual seria o resultado desejado.

Várias instalações de pacotes de serviços

P Tenho oito instâncias agrupadas em um cluster de 4 nós e gostaria de instalar o SP4 com o mínimo de reinicializações. Posso instalar o SP4 em todas as 8 instâncias, uma depois da outra, e no final reinicializar todos os nós?

R Depois de ter instalado completamente uma única instância do SQL Server SP 4 - o que pode exigir uma reinicialização - em um determinado servidor Windows (em cluster ou não), não devem acontecer mais reinicializações depois de instalar o SQL Server SP4 em qualquer outra instância do SQL Server na caixa. O motivo é que todos os arquivos compartilhados — ferramentas, MDAC, MSXML e assim por diante — já estão com a versão certa e, bloqueados ou não, não necessitam de atualização adicional. Todos os arquivos não compartilhados são usados apenas pela primeira instância, que será desligada pela instalação. Vale a pena notar que a instância mais recente do SQL Server deverá ser atualizada primeiro, se houver várias instâncias com diversas versões.

Execução como serviço de rede

P O que exatamente é a conta NT AUTHORITY\NETWORK SERVICE e qual a sua principal finalidade? Além disso, quais são as implicações de segurança dessa conta, especialmente se lhe forem dados direitos sysadmin (administrador do sistema)?

R A conta Network Service (Serviço de Rede) tem a mesma identidade (de máquina) que System (Sistema) na rede, mas possui privilégios limitados na caixa local. Assim, se um serviço exigir acesso a recursos da rede, pode ser que, para resolver nomes de conta com o controlador de domínio, ele tenha que ser executado seja como Sistema, como conta de domínio ou Serviço de Rede. Normalmente, esta última é a escolha mais segura, pois seu escopo se restringe apenas à caixa local e ainda assim tem privilégios limitados.

Tornar o Serviço de Rede um sysadmin no SQL Server significa que qualquer outro serviço em execução como Serviço de Rede em uma caixa local tem controle total sobre o servidor. Isso acontece, por exemplo, quando a conta de serviço do SQL Server é configurada para execução como Serviço de Rede. Tornar uma conta de serviço do SQL Server um membro de sysadmin é necessário para a funcionalidade do servidor (por exemplo, para permitir conexões de loopback). Embora ter o Serviço de Rede executado como administrador no SQL Server não seja uma boa prática de segurança, isso pode (ou não) ser melhor do que usar uma conta de domínio para esse fim e – muito mais seguro do que executar o SQL Server como LocalSystem.

Se você não quiser que o Serviço de Rede tenha privilégios de sysadmin, a próxima escolha a explorar é usar uma conta de domínio especificamente dedicada a executar SQL Server em uma ou mais instalações do Windows NT®.

Os seguintes artigos podem lhe ajudar: msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp e microsoft.com/technet/security/topics/serversecurity/serviceaccount.

Criação de vários bancos de dados

P Estou pensando em particionar os dados em bancos de dados individuais, talvez em até 250 bancos de dados online ao mesmo tempo. Estimo que apenas 20 por cento serão utilizados nas consultas ativas, a qualquer tempo. Muitos bancos de dados é melhor do que poucos?

R O número de bancos de dados em uma instância de servidor de bancos de dados deve ser conduzido segundo as necessidades de negócio e fatores administrativos. Há muito pouca sobrecarga quando vários bancos de dados são criados em uma mesma instância de servidor; mas a existência de mais bancos de dados significa mais sobrecarga administrativa quanto a tarefas de manutenção, como backup e restauração, espelhamento, contas e funções de usuário. As complexidades administrativas adicionais podem ultrapassar as vantagens de ter mais bancos de dados.

Como regra geral, todos os dados relacionados a um aplicativo devem ser mantidos em um mesmo banco de dados, para facilitar a recuperação na eventualidade de falhas. Se os dados de um aplicativo estiverem espalhados em vários bancos de dados, todos esses bancos de dados terão que ser recuperados durante um failover. Isso poderá atrasar a recuperação ou, até mesmo, impedi-la, caso um dos bancos de dados não possa ser recuperado.

Isto posto, também existem bons motivos para separar dados em vários bancos de dados:

• Um subconjunto de dados possui requisitos de backup diferentes dos outros dados.
• Certos dados precisam de um contexto de segurança separado, isto é, de um proprietário de banco de dados diferente.
• Às vezes, existem dados para fins de histórico que precisam ser mantidos no modo somente leitura.

Agradeço aos seguintes profissionais de TI da Microsoft por seu conhecimento técnico: Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson e Madhusudhanan Vadlamaani.

Editado por Nancy Michell

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..