Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de Usuários
»Células Acadêmicas«
intcontpiada : 118
Guilherme Tell
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
Faça um pequeno teste com 10 questões de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programação com nosso treinamento on-line de lógica de programação
.:.
Veja nosso calendário de treinamentos
Gostou da Página?
Então

para um amigo!
 







Pesquisa personalizada
Pesquisar Dicas:

 






Controlando versões de objetos entre ambientes de desenvolvimento e um pouco mais sobre entrada de sistemas em produção

Inicialmente pode-se imaginar que a transferência de objetos entre o servidor de banco de desenvolvimento e o de produção, onde a aplicação irá rodar, é algo simples, especialmente porque o SQL Server possui o recurso de gerar scripts de objetos, então a principio bastaria gerar os scripts e inserir no novo servidor. Mas existem muito mais detalhes nessa tranferência do que normalmente se imagina e são esses detalhes que tornam o processo de transferência complexo e imprevisível. Perdas de dados, erros de versionamento, perdas de objetos, são apenas alguns dos possíveis problemas neste processo. Vamos analisar então o que envolve a transferência de um banco do ambiente de desenvolvimento para a produção da empresa.

Primeiramente, normalmente não são dois ambientes, mas 3: O de desenvolvimento, onde o desenvolvedor trabalha, o de qualidade (ou homologação, mas existem outros nomes) onde são feitos testes do sistema antes de sua entrada em funcionamento e o ambiente de produção, que é onde o sistema irá rodar.

Vamos então analisar como é a transferência dos objetos do banco através destes ambientes. Podemos classificar a transferência em 2 níveis de complexidade: Os objetos de dados, ou seja, tabelas, que são sem dúvida os mais complexos de serem transferidos, devido aos próprios dados. Já os objetos de negócio, como views, triggers e procedures, apesar de terem sua complexidade, possuem um processo de transferência bem mais simples.

Veremos agora tudo que envolve este processo de transferência de servidor e um pouquinho sobre a entrada do banco em produção.

Padrão de Nomenclatura

A primeira coisa necessária para organizar a transferência é saber que objetos deverão ser transferidos. Quando a transferência é feito pela primeira vez, o processo é fácil, transfere-se tudo. Mas depois que o sistema está no ar deve-se ter o cuidado de transferir apenas as diferenças entre versões do sistema. Um passo importante para esta organização é que haja um padrão de nomenclatura que facilite a identificação dos objetos que encontram-se relacionados entre si.

Todo sistema possui pequenas sub-divisões, pequenos módulos. É importante que o DBA possa bater o olho na lista de objetos e identificar de cara quais objetos pertencem a qual módulo ou a qual parte do sistema.

A questão é : Os objetos devem possuir agrupamentos: sistema, módulo, funcionalidade, o que for, eles devem estar agrupados através de seus nomes. Assim sendo, digamos que na sua empresa existem vários sistemas. Cada sistema possui vários módulos e cada módulo várias funcionalidades.

Será necessário então criar siglas para os sistemas, para os módulos e para as funcionalidades. Sempre lembrando que os objetos quando visualizados pelo enterprise manager estarão em ordem alfabética. Assim sendo, as siglas e a ordem alfabética garantirão que objetos relacionados entre si (com uma mesma funcionalidade, ou do mesmo módulo) sempre estarão próximos quando listados, facilitanto sua visualização. Bastará o DBA bater o olho na lista de objetos e já saberá o que tem que ser transferido.

...................................................................................................................................

Acredito que algumas questões básicas de nomenclatura nem precisam ser citadas. Por exemplo, já é de conhecimento geral que não se pode utilizar sp_ na frente dos nomes das procedures devido a grande perda de escalabilidade que o nome reservado sp_ causa.

Por que nunca usar o prefixo SP_ em stored procedures

As procedures de sistema do SQL Server são precedidas pelo prefixo SP_ . Isso soa aos DBA's como um padrão de nomenclatura de procedure.

Em uma dica anterior mencionamos que quando uma procedure é precedida por SP_ o SQL Server busca a procedure no banco Master. Isso permite que sejam criadas procedures globais para administrar o servidor. Essas procedures podem ficar no Master e serem chamadas a partir de qualquer banco que o SQL Server as encontra.

Então por que não devemos nomear todas nossas procedures como SP_ ?

O SQL Server mantém um cache de planos de execução das procedures. Assim sendo, quando uma aplicação executa uma procedure primeiramente ele procura esta procedure no cache, se estiver lá utiliza estas informações, caso contrário terá que recompilar.

A versão 7 e superiores mantém apenas 1 cópia de cada procedure no cache de procedures. Para garantir isso o SQL Server precisa ter certeza que, recebendo 2 pedidos simultâneos para a mesma procedure, não tentará compila-la 2 vezes. Assim sendo, durante o processo de compilação o SQL Server gera um lock, chamado de compilation lock, que impede que outras aplicações compilem a procedure ao mesmo tempo.

Ocorre que o compilation lock é gerado imediatamente após a procura no cache. Ou seja : o SQL Server busca a procedure no cache, se não achar, gera o lock. E dai ?

Quando a procedure tem o prefixo SP_ ela é primeiramente procurada no Master e não no banco em que o usuário está. Quando a procedure não é encontrada no Master é gerado o compilation lock. Posteriormente, antes de compilar a procedure, o SQL Server acaba descobrindo que ela já está no cache de procedures do banco de dados do usuário e reaproveita o cache, sem recompilar a procedure. Porém TODAS as chamadas desta procedure vão estar gerando o compilation lock e prejudicando seriamente o tempo de execução da procedure.

Devido a isso, evite utilizar o prefixo SP_ nas suas procedures, utilize apenas quando necessário, para procedures administrativas.

...................................................................................................................................

Existem muitos objetos que não podem ter nomes duplicados a nível de banco, tais como chave primária, estrangeira, índices, constraints, etc. Mas muitos talvez não tenham percebido algumas características importantes na nomenclatura destes objetos. Podemos dividir estes objetos em dois grupos importantes, que devem ser tratados separadamente: Os que já possuem um padrão de nomenclatura sugerido pelo SQL Server e os que não possuem.

Os objetos que normalmente são gerados por meios visuais, tais como constraints, chaves primárias, chaves estrangeiras, entre outros , já possuem um padrão de nomenclatura. Se você tentar impor um padrão de nomenclatura diferente do padrão utilizado pelas ferramentas gráficas usadas em sua empresa (mesmo que seja apenas o Enterprise Manager) você irá causar uma grande perda de tempo para os analistas, eles irão se rebelar contra seu padrão, você terá dificuldades para mante-lo, etc.,etc. Tudo porque é por demais trabalhoso dar nomes aos objetos um por um. Você estaria simplesmente desperdiçando os recursos da ferramenta.

Portanto, analise os padrões de nomenclatura da ferramenta gráfica que sua empresa utiliza (Enterprise manager, VS, ErWin, Rational Rose, Visio, System Architect, Visual UML, entre outras) e use os padrões de nomenclatura da ferramenta. A adesão aos padrões será automática e transparente.

Já para os outros objetos, que não possuem um padrão de nomenclatura pré-definido, comece seguindo uma regra básica. É tão básica que muitos diriam : Para que escrever isso ? Ocorre que apesar de básica essa regra nunca é obedecida, então é bom escrever mais uma vez : FAÇA OS PADRÕES ANTES DE COMEÇAR O SISTEMA, NÃO NO MEIO DELE. Você não vai querer gastar 2 a 3 horas dos analistas (R$ 40,00/ hora X 3=R$ 120,00) apenas para que fiquem trocando os nomes de objetos para entrarem no padrão, tudo porque você resolveu fazer um padrão quando o sistema já estava pela metade, vai ?

Então planeje os padrões antes de começar o sistema, pensando em todos os detalhes e observando as facilidades (ou dificuldades) que a ferramenta (tal como o enterprise manager) irá criar para você por causa do padrão escolhido por você.

Iniciando a transferência dos objetos

O inicio do processo de transferência é razoavelmente simples. A principio seria apenas gerar o script no servidor de desenvolvimento e rodar o script no servidor de qualidade, o próximo estágio na construção da solução.

Normalmente, porém, é o desenvolvedor o responsável por gerar o script em ambiente de desenvolvimento, mas é o DBA da empresa que irá validar este script e executa-lo em ambiente de homologação. É necessário então que o inicio da transferência de objetos garanta o inicio do controle de versão que deverá existir entre o trabalho do desenvolvedor e do DBA.

O controle de versão deve ser feito por objeto, para que possam posteriormente existir atualização incremental. Portanto o script deve ser gerado por objeto, não inteiro. Na geração de script do SQL Server temos uma opção que nos permite gerar um arquivo por objeto. Isso será necessário para iniciarmos o processo de controle de versão dos objetos.

Mas o controle de versão dos objetos não pode ser feito apenas utilizando arquivos, seria fácil demais cometer falhas neste controle. Precisamos utilizar um software que faça controle de versão dos arquivos que utilizaremos, tal como o Visual Source Safe, pois só assim conseguiremos um controle adequado de versionamento dos arquivos. Cabe ao DBA garantir que o software de controle de versão escolhido, tal como o VSS, seja amplamente utilizado. Uma forma de garantir isso é, por exemplo, não aceitar nunca receber os arquivos diretamente dos desenvolvedores. Quando o desenvolvedor solicitar que o banco em ambiente de qualidade seja atualizado, buscar sempre os arquivos no source safe. O Source Safe pode funcionar como um repositório de arquivos, servindo para a transferência de arquivos do desenvolvedor para o DBA. Desta forma se o desenvolvedor não mantiver o source safe atualizado o sistema simplesmente não funcionará em ambiente de qualidade.

Executando os Scripts

O DBA porém terá um problema : Como executar os arquivos no SQL Server ? Executar arquivo por arquivo pode ser por demais complicado.

Para resolver este problema o DBA pode recorrer aos velhos recursos aprendidos no DOS. Podemos criar um arquivo de lote com apenas duas instruções para fazer a execução dos arquivos que o DBA determinar. Veja como fica esse arquivo de lote :

echo off
for %%f in (%1) DO OSQL -E -d northwind -i %%f

Vamos decifra-lo por partes. O arquivo de lote faz uso do OSQL do SQL Server. O parâmetro -E identifica conexão integrada (assim não é necessário ter a senha guardada neste arquivo). O parâmetro -d indica o banco a ser aberto após a conexão com o sql server. Por sua vez o parâmetro -i indica que desejamos apenas executar as instruções que estão contidas em um arquivo.

A instrução for, uma instrução de prompt, faz com que a instrução que encontra-se após o DO seja executada diversas vezes, uma vez para cada elemento que encontra-se após o IN.

Mas após o in o que temos é %1. Este %1 representa o parâmetro passado para este arquivo batch quando ele for disparado via prompt. Poderemos então disparar este arquivo passando como parâmetro *.sql , ou até *.* . O for será executado para cada arquivo do conjunto informado e a cada execução provocará a chamada do OSQL.

O %%f é uma variável utilizada no for. Em cada execução essa variável fica representando o nome do arquivo para o qual a execução está sendo feita. Para quem conhece VB, isso é muito semelhante a um for each . O echo off é uma instrução de prompt que está solicitando para que as instruções do arquivo batch não sejam exibidas na tela antes de serem executas, o que acontece por default.

Assim sendo o DBA, quando for criar os objetos de banco no ambiente de qualidade, pode baixar os arquivos do source safe e utilizar esse arquivo batch (que podemos chamar de executar.cmd) para executa-los, algo como :

Executar *.sql

Para identificar o que está ocorrendo durante a execução o DBA pode acrescentar ao OSQL o parâmetro -o e indicar o nome de um arquivo de output, algo como RESULTADO.TXT . Depois basta conferir o arquivo para verificar o que ocorreu.

Validando os scripts transmitidos

É no momento da passagem dos objetos de banco do ambiente de desenvolvimento para o ambiente de qualidade que o DBA deve realizar a validação dos scripts que recebe e, claro, devolve-los ao desenvolvedor se houverem erros para corrigir.

A questão não são as tabelas, pois o DBA deve ter participado da modelagem do banco anteriormente, isso é uma regra que deveria (pelo menos deveria) ser seguida por todas as empresas. A questão são as procedures, sobre as quais o DBA certamente terá muita dificuldade de manter o controle. É no momento de implantação das procedures no ambiente de qualidade que o DBA deve checa-las. Mas a questão é : Como checar 100 ou mais procedures que o sistema pode possuir ?

Um truque que auxilia esta tarefa é utilizar querys sobre a tabela syscomments para identificar problemas mais graves relativos ao descumprimento de padrões de desenvolvimento. Veja alguns exemplos :

Identificando a falta de Set NoCount On : O Set Nocount on é uma instrução que, quando utilizada nas procedures, garante uma melhor otimização das procedures, pois evita que a contagem de registros afetados, aquela que normalmente é mostrada pelo query analyzer, seja gerada e transmitida pela rede. Portanto o DBA deve identificar procedures que estejam sem o Set NoCount On. Claro que ele não poderá olhar uma por uma, serão muitas. Para resolver isso podemos realizar querys sobre a tabela syscomments, que contém o código fonte de todas as procedures geradas. Eis a instrução SQL para fazer isso :

select name from syscomments a,sysobjects b where a.id=b.id and b.xtype='P' and not exists (select id from syscomments where text like '%set%nocount%on%' and id=a.id) order by name

Identificar procedures que utilizam cursores : Cursores geram grande prejuizo para a performance. O DBA precisa identificar procedures que fazem uso de cursores e analisa-las para garantir que não existe nenhuma forma alternativa de escrevê-las.

Eis a instrução SQL para fazer isso :

select a.id,b.name from syscomments a,sysobjects b where a.id=b.id and a.text like '%open %'

  Identificar procedures que utilizam tabelas temporárias : As tabelas temporárias geram grande consumo de performance, podem gerar problemas quando utilizadas em ambientes que realizam poolings de conexão. Desta forma cabe ao DBA analisar procedures desenvolvidas com tabelas temporárias e verificar se não existem formas alternativas de codifica-las. Eis a instrução SQL para identificar tais procedures :

select a.id,b.name from syscomments a,sysobjects b where a.id=b.id and a.text like '%#%'

Identificar procedures que estejam utilizando UNION sem ALL : A falta do ALL no UNION dificulta uso de índices e prejudica a performance da aplicação. O DBA precisa identificar procedures que estejam utilizando UNION sem ALL e corrigir o problema.

Veja o script para identificar tais procedures :

select a.id,b.name from syscomments a,sysobjects b where a.id=b.id and a.text not like '% UNION ALL%' and a.text like '% UNION %' and b.xtype='P'

Identificar procedures que estejam fazendo montagem e execução de strings : A montagem e execução de strings é extremamente prejudicial para a performance, pois o SQL Server só é capaz de determinar como a execução será feita em run-time. Quando existe alternativa, é preferível evitar isso. Mais uma vez cabe ao DBA identificar e corrigir este problema. Veja a instrução utilizada para identificar isso :

select a.id,b.name from syscomments a,sysobjects b where a.id=b.id and (a.text like '%EXEC(%' or a.text like '%execute(%')

 

Cuidado com os Triggers

Os triggers são os objetos mais delicados para o processo de transferência. Isso porque o trigger não é claramente visivel entre os objetos do banco de dados (via enterprise manager) e a falta do trigger não faz com que a aplicação pare de funcionar de imediato. Por isso não é raro acontecer de na implantação da aplicação um trigger ser esquecido para trás e a falta dele só ser notada tempos depois da aplicação já estar funcionando.

O DBA deve, então, ter extremo cuidado com os triggers, garantindo que nenhum seja esquecido para trás. Uma solução é fazer uma query que crie uma listagem de todos os triggers existentes no banco e suas respectivas tabelas. Executando a query nos dois bancos o DBA poderá, com certa facilidade (afinal, na metodologia de desenvolvimento para banco, o uso de triggers é excessão, não regra, por isso haverão poucos), verificar se todos os triggers estão presentes ou não.

Veja a query para obter uma listagem dos triggers e suas respectivas tabelas :

select name,object_name(parent_obj) tabela from sysobjects where xtype='TR'

Como o volume de triggers normalmente não é muito grande, pois é dada preferência ao uso de procedures, uma simples comparação visual desta lista pode ser suficiente para resolver o problema.

Utilizando DDL transacional

Quando o DBA roda um script para atualização de objetos no banco nem sempre o script funciona na primeira tentativa. Um erro aqui, outro ali, sempre pode acontecer. Se o script falha, o DBA se vê obrigado não apenas a corrigir o script, mas também verificar quais partes do script rodaram e quais não, separa-las e executar novamente apenas os trechos que falharam.

Essa é, com certeza, uma tarefa muito trabalhosa. Para simplificar um pouco a tarefa podemos utilizar um excelente recurso do SQL Server : O recurso de executar instruções DDL de forma transacional. DDL é a abreviação de Data Definition Language, é o nome que damos para instruções de criação de objetos de banco. As instruções DDL no SQL Server podem ser inseridas dentro de uma transação, o que é um excelente recurso para o DBA.

O DBA pode, antes de rodar um script, utilizar a instrução Begin transaction para abrir uma transação e só então rodar o script. Se tudo funcionar, utiliza-se então a instrução Commit transaction. Se o script gerar uma falha qualquer, utiliza-se rollback transaction.

Com isso se o script falhar tudo que tiver sido feito será desfeito, permitindo que o DBA execute o script todo novamente, sem ter que ficar separando o que foi ou não executado.

O recurso de DDL transacional é muito importante na passagem de correções do sistema do ambiente de qualidade para o ambiente de produção. Essa é uma tarefa muito delicada, pois há o risco dos dados de produção serem afetados. O DBA pode então juntar os scripts de atualização em um único arquivo e executa-lo usando o recurso de DDL transacional.

Transferindo domínios

Toda aplicação sempre possui uma série de tabelas de domínios. Chamamos de tabelas de domínios tabelas que contenham informações de referência para as tabelas de informações do sistema. Por exemplo, tabelas contendo a lista de estados do país, a lista de valores para o campo estado civil, lista de profissões, entre muitas outras.

Estes valores normalmente precisam ser previamente inseridos no banco de dados para que a aplicação funcione. Por isso é interesante que a inserção dos valores de domínio faça parte dos scripts de transferência do banco de dados entre os ambientes de desenvolvimento.

Mas o SQL Server não possui um mecanismo que nos permita transformar em script as informações guardadas nas tabelas. Então para fazer isso você precisará utilizar uma procedure criada com essa finalidade. Não vou publicar aqui o código da procedure, pois é complexo, mas você pode obte-la no endereço http://www.bufaloinfo.com.br/dicas.asp?cod=104

Identificando o ponto zero

Costumo chamar de ponto zero do banco os momentos durante o processo de construção de uma solução em que não existe necessidade de realizar a evolução do banco. São momentos nos quais o DBA tem completa liberdade para apagar o banco por inteiro e recria-lo.

Nestes momentos, nos pontos zero, o DBA pode simplesmente obter um script completo do banco e executa-lo no ambiente em que deseja fazer a atualização. Isso torna o processo bem simples para o DBA.

Cabe ao DBA identificar a existência destes momentos. Existem 2 pontos zero básicos, fáceis de serem identificados :

Depois do sistema haver iniciado seu trabalho em produção não existem mais ponto zero. Os dados utilizados em produção exigem que os objetos sempre sejam atualizados através de scripts de evolução e não scripts que refaçam a criação dos objetos.

Com o sistema em produção o "ponto zero" não pode acontecer nem mesmo no ambiente de qualidade, pois se ocorresse, a sequencia de scripts para atualizar o ambiente de produção seria perdida, já que o ponto zero representa o reinicio da sequencia de scripts de versionamento.

Depois da criação do banco em qualidade e antes da criação do banco em produção podem existir, ou não, outros pontos zero, quando o banco de qualidade possa ser recriado por completo. A questão que deve ser feita sempre é : Existem informações no banco em ambiente de qualidade que impedem que o banco seja recriado novamente do zero? A partir do momento em que existem informações assim o DBA precisa ter um cuidado extremo em toda alteração de estrutura de tabela que venha a acontecer, para que os scripts gerados sejam evolutivos e não de recriação das tabelas.

Criando scripts evolutivos

Um dos grandes desafios para o DBA é garantir que, depois da aplicação estar em produção, apenas sejam gerados scripts evolutivos para a realização de alterações nas tabelas e objetos relacionados a elas. O DBA deve garantir que nunca sejam gerados scripts que possam destruir os dados existentes no ambiente de produção da empresa.

Neste cenário o enterprise manager é ao mesmo tempo herói e vilão. Ao mesmo tempo que nos ajuda, criando scripts evolutivos para os objetos de banco, basta uma simples distração nossa para que o script seja perdido ou o banco destruido.

Existem certas operações que não podem ser feitas diretamente via script. Ou melhor, até podem, mas seriam extremamente trabalhosas.

Por exemplo, trocar o tipo de dados de uma chave primária que possui relacionamentos com outras tabelas. Seria um processo extremamente trabalhoso fazer isso via código. O Enterprise Manager realiza esse processo automaticamente para nós. A pergunta que normalmente surge é : Se este é um processo muito complexo via código como o Enterprise Manager consegue realiza-lo ?

Ocorre que o Enterprise Manager foi preparado para contornar limitações do servidor através de alterações no modelo de dados.

No exemplo, se trocamos o tipo de dados da chave primária o enterprise manager se encarrega de eliminar as constraints (PK e FK, ou seja, nas duas tabelas) e até mesmo recriar a tabela para que a troca de tipo seja possível, transferindo todos os dados da antiga tabela para a nova tabela, recriada. Isso tudo, claro, sem esquecer de recriar as constraints ao final.

Figura 1 : Geração de script feita pelo Enterprise manager durante uma alteração de estrutura de tabela

Assim sendo, o trabalho realizado automaticamente pelo Enterprise Manager é exatamente o que precisamos : uma evolução das tabelas existentes no banco com o cuidado de manter todos os objetos e dados. O enterprise manager, felizmente, nos permite fazer a gravação dos scripts que ele utiliza para gerar essas modificações. Desta forma podemos não apenas gerar as modificações com facilidade como podemos também salvar os scripts e reproduzir as modificações em outros servidores.

Mas o Enterprise Manager se torna um grande vilão quando percebemos que basta um clique em um botão errado para perdermos toda a possibilidade de gerarmos este script . O botão para geração do script fica exatamente ao lado do botão salvar. Se nos confundirmos e por engano clicarmos em salvar, o enterprise manager irá executar as alterações e não poderemos mais salvar o script. Ou seja, temos apenas uma chance de salvar o script, se clicarmos no botão errado, teremos problemas.

Além do cuidado que o DBA deve ter para não errar existe também a questão da sequencia de arquivos. O DBA precisa organizar os arquivos de forma a que possa identificar facilmente a sequencia de execução dos arquivos. Assim sendo precisará planejar como fazer essa organização, que envolve a nomenclatura dos arquivos. Veja algumas possibilidades

Desta forma, gerando os scripts evolutivos e mantendo os arquivos organizados, no momento da implantação bastará executar os scripts na ordem correta para reproduzir as mesmas alterações criadas em ambiente de desenvolvimento.

Após a implantação

Após ter realizado a implantação o DBA precisa iniciar uma análise detalhada da aplicação para saber se em produção ela se comportará conforme planejado durante o desenvolvimento. Para isso o DBA conta com o System Monitor e o Profiler. O DBA utilizará o System Monitor para identificar se existem problemas e, caso existam, utilizar o Profiler para localizar o problema com maior precisão.

O DBA deve montar um gráfico e manter a análise dos seguintes índices :

sqlServer:DataBases

Percent log usage : Este índice vai informar ao DBA o percentual utilizado do log. Com isso o DBA irá verificar se a previsão de crescimento do log está correta e a periodicidade de backup encontra-se adequada

SQLServer:Locks

Lock Timeouts/Sec : Um número excessivo de timeouts pode significar problemas. Mesmo que a aplicação não esteja registrando nenhum erro, pode significar dificuldade do sql server em manipular os dados (executar um split, por exemplo) devido a um volume muito grande de acessos. Em alguns casos um replanejamento de índices visando definir a ordem física dos dados pode ajudar.

DeadLocks/sec : Isso significa falha de programação. Se estiverem ocorrendo o DBA precisará utilizar o profiler para identificar em que momentos ocorre e poder avisar ao programador quais transações geram esta falha.

SQLServer:SQLStatistics

SQL Re-Compilations/sec : Um excesso de recompilações indica problema nas stored procedures. Eventualmente algumas combinações de instruções nas procedures podem causar um excesso de recompilações das procedures. Isso afeta a performance do SQL Server.

SQLServer:AccessMethods

Full Scans/sec : A ocorrência de Full Scans indica a falta de índices em tabelas ou problemas com o planejamento dos índices. Se o volume de Full Scans estiver alto é necessário replanejar os índices.

Page Splits/sec : Um alto volume de page splits indica problemas de fragmentação, consequentemente a necessidade de replanejar os índices, em especial a configuração de Fill Factor dos índices

SQLServer:Cache Manager

Cache hit Ration

Procedure Plans : O cache hit ratio de procedures deve ser mantido alto. Se este índice estiver baixo isso índica que certamente estão ocorrendo excessos de compilações de procedures (SQL Re-Compilations/sec estará alto). Consequentemente indica a necessidade de corrigir procedures na aplicação.

Conclusão

O processo de implantação de um banco em produção as vezes parece simples, mas se o DBA se descuidar dos detalhes que mencionei aqui muitos imprevistos ocorrerão na passagem do banco para produção. Um bom planejamento é essencial desde o inicio do projeto do sistema

Dennes Torres
MCSD,MCSE,MCDBA

Dennes Torres é diretor da Búfalo Informática e responsável técnico pelo site http://www.bufaloinfo.com.br , onde normalmente é encontrado nos fóruns de discussão.

 

 



� Búfalo Informática, Treinamento e Consultoria - Rua Álvaro Alvim, 37 Sala 920 - Cinelândia - Rio de Janeiro / RJ
Tel.: (21)2262-1368 (21) 9240-5134 (21) 9240-7281 e-Mail:
contato@bufaloinfo.com.br