Gerenciando o Crescimento de Dados No SQL Server

15/7/2014 Gerenciando o crescimento de dados no SQL Server
https://www.simple-talk.com/sql/database-administration/managing-data-growth-in-sql-server/ 1/22
Q
Gerenciando o crescimento de dados no SQL Server
21 de janeiro de 2010
por Rodney Landrum
'Ajuda, meu banco de dados comeram meus discos!'. Muitos DBAs gastam a maior parte de seu
tempo lidando com variaes do problema dos processos de banco de dados que consomem
muito espao em disco. Isso acontece por causa de erros, tais como configuraes incorretas de
modelos de recuperao, o crescimento de dados para objetos grandes e consultas que
sobrecarregam os recursos tempdb. Rodney descreve, com algum sentimento, os erros que podem
levar a esse tipo de crise para o DBA a trabalhar, e sua soluo.
uando eu olho para trs na minha carreira como DBA SQL Server, analisando os tipos de questes que tive de
resolver, geralmente sob presso, nada me leva a suar frio do que os dados de fugitivos, faa o login ou
arquivo tempdb. Eu estimaria que por cada vez que eu tive que lidar com uma emergncia de restaurao,
incluindo ponto no tempo restaura usando backups do log de transaes, eu provavelmente j teve de lidar com
problemas de capacidade em disco cem. No geral, eu estimaria que essas questes representam cerca de 80%
dos problemas que uma equipe DBA enfrenta em uma base semanal.
Ocasionalmente, a causa desses problemas de espao o planejamento de capacidade apenas pobres. Em
outras palavras, o crescimento no tamanho do arquivo era inteiramente previsvel, mas algum deixou de planej-
la. Padres de crescimento previsveis so algo que deve ser analisada logo no incio, de preferncia antes do
SQL Server mesmo instalado. Na minha experincia, no entanto, estas questes espaciais so geralmente
causados por erros ou falta em aderir s melhores prticas.
Neste artigo, vou aprofundar as causas mais comuns de problemas de gerenciamento de espao, cobrindo a
configurao do banco de dados modelo, modificaes em massa ineficientes, ndices e abuso TempDB, e como
corrigi-los. Vou terminar o artigo descrevendo uma consulta que voc deve armazenar de forma segura em seu
tacklebox o SQL Server, SizeQuery . Eu uso esta pergunta em mais ou menos uma base diria para monitorar e
controlar a utilizao do espao em minhas instncias do SQL Server. Utilizado em conjunto com o repositrio de
DBA para consultar vrios servidores SQL, ele provou ser uma ferramenta de comunicao de valor inestimvel.
Eu dei um nome para o tempo na parte da manh em que um DBA normalmente cambaleia para trabalhar, turvos
olhos, depois de ter passado a maior parte da noite anterior encolhendo os arquivos de log e de lavagem de
discos para cada Gigabyte preciosa de dados, a fim de encontrar espao suficiente para limpar um alerta. Esse
nome DBA: M (pronuncia-se D-BAM), e geralmente em torno de 09:30. Meu principal objetivo com este artigo
para ajudar companheiros DBAs evitar que DBA: M sentimento.
As causas mais comuns de problemas de espao
As questes a seguir esto entre as mais-comum de DB tristeza relacionada com o espao:
Mal configurado banco de dados modelo - o que significa que os bancos de dados subseqentes adotar
propriedades (aumento automtico, modelo de recuperao e assim por diante) que so inadequadas para
o uso pretendido.
Ineficiente DELETE, INSERT ou INSERT em massa - tais processos, mais aqueles que criam tabelas
temporrias, pode rapidamente preencher o arquivo de log com dados desnecessrios. A situao
agravada pela configurao do banco de dados modelo incorreto.
ndices e grandes contagens de linha - ndices cluster pode levar at um monte de espao para tabelas
que contm milhes de linhas de dados. No entanto, voc s precisa se planejar para isso, porque as
conseqncias de no ter esses ndices podem afetar seriamente o desempenho.
Abuso flagrante de TempDB - As tabelas temporrias muitas vezes desempenham um papel importante
quando os desenvolvedores tm a tarefa de comparar milhes de linhas de dados, para retornar um
pequeno subconjunto de resultados. Esta prtica pode ter conseqncias indesejveis, tais como,
Junte-Simple-Talk Entrar
Search...
inadvertidamente, preenchendo o banco de dados tempdb. o nosso trabalho, como DBAs, para ter certeza
isso no acontece, muitas vezes, atravs da realizao de uma reviso de cdigo e oferecendo uma
soluo alternativa.
Ao longo dos prximos sees, vou aprofundar cada uma dessas questes, e discutir as tcnicas que tenho
usado para analisar e corrigir cada um, sempre que possvel. Digo "sempre que possvel", porque s vezes o
crescimento de dados realmente exceda todas as expectativas e confundir at mesmo o planejamento de
capacidade mais rigorosa. O nico curso de ao, em tais casos, expandir discos ou adicionar espao adicional
SAN, as coisas s perifericamente conhecido de muitos DBAs.
Quero salientar que este artigo no vai brilhar uma luz sobre internos do SQL Server. Eu no vou estar levando voc
a uma viagem ao corao do motor de banco de dados para explorar os conceitos esotricos de armazenamento
nvel folha. Cada DBA precisa entender onde e como objetos, como tabelas e ndices, use o espao em seus
servidores, e ser muito familiarizado com os conceitos fundamentais, como pginas, extenses, os fatores de
enchimento, bem como a fragmentao interna e externa. No entanto, vou deixar os detalhes para Books Online.
Aqui, tenho a inteno de conduzir o All Terrain Vehicle da minha experincia direto fonte dos problemas de
alocao de espao que causar estragos na vida de viglia e sono do DBA de planto.
Sendo um modelo de DBA
Este artigo sobre a utilizao do espao no SQL Server e no h lugar melhor para comear do que com o banco
de dados modelo. A primeira coisa que eu vou dizer sobre o banco de dados do modelo que, se fosse por mim,
eu iria mudar o nome. Fora da caixa, no h nada de "modelo" a respeito; ele no um cidado "modelo" nem
deve ser considerado um "modelo" para outros bancos de dados. No entanto, o modelo sobre o qual todas as
bases de dados subsequentes so baseadas, incluindo TempDB. Em outras palavras, os novos bancos de dados
criados no servidor, a menos que especificado em contrrio, ir herdar as definies de configurao do banco de
dados modelo.
A lista completa de opes para o banco de dados do modelo, incluindo suas configuraes padro, pode ser
encontrada em http://technet.microsoft.com/en-us/library/ms186388.aspx. Os padres para a maioria das opes
so muito bem para a maioria dos bancos de dados. Mais significativamente, no entanto, as configuraes do
banco de dados modelo determinar o seguinte:
Aumento automtico propriedades para os dados e arquivos de log
Modelo de recuperao do banco de dados
As configuraes padro para cada uma delas definitivamente no apropriado para todos os bancos de dados, e
fcil para os novos DBAs, ou mesmo nos antigos DBAs abatido, se esquecer de verificar essas configuraes
especialmente quando estamos trabalhando com um servidor configurado por um DBA anterior.
Cuidado com o aumento automtico e recuperao padro
Por padro, o arquivo de dados (modeldev) para o banco de dados do modelo, tanto para o SQL Server 2005 e
2008 ser de cerca de 3MB em tamanho, inicialmente, e est definido para crescimento automtico em 1 MB
(1.024 K), sem restries, incrementos at que o disco est cheio . O arquivo de log de um tamanho inicial de
2MB e est previsto para crescer em incrementos de 10%, mais uma vez at que o disco est cheio. Estas
configuraes so mostradas na Figura 1.
Nota: Microsoft SQL Server 2008 Books Online afirma: ". Os tamanhos desses arquivos pode variar
um pouco para diferentes edies do SQL Server" Eu estou usando Standard Edition para os
exemplos neste artigo.
Em termos de armazenamento do SQL Server, 1024K de 128 pginas; pginas so armazenadas em blocos de
8K. Para aplicaes que vo carregar potencialmente milhes de registros, o crescimento do arquivo de dados de
um banco de dados a cada 128 pginas incorre em um grande impacto no desempenho, uma vez que um dos
principais gargalos do SQL Server solicitaes de E / S.
Figura 1: tamanhos iniciais e caractersticas de crescimento para os dados do banco de dados modelo e arquivos
de log.
Ao invs de aceitar esses padres, uma prtica muito melhor para o tamanho do arquivo de dados de forma
adequada no incio, em dizer 2G. O mesmo conselho se aplica para o arquivo de log. Geralmente, o crescimento
com base numa percentagem muito bem at que o arquivo atinge um limite onde o prximo crescimento vai
consumir todo o disco. Vamos dizer que voc tinha um arquivo de log em uma unidade de 40G 50G. Levaria
apenas dois 10% crescimentos para encher o disco, e ento os alertas sair e voc deve acordar, com os olhos
turvos, a encolher os arquivos de log e amaldioar o banco de dados modelo.
Juntamente com as caractersticas de crescimento de arquivo anteriormente descritos, os nossos bancos de
dados tambm vai herdar do banco de dados modelo padro um modelo de recuperao de completa .
Movimentaes no arquivo de log para um banco de dados de recuperao completa so sempre apenas
removido do log sobre um backup do log de transaes. Isso maravilhoso para a prestao de ponto no tempo
de recuperao para aplicaes crticas de negcios que exigem Acordos de Nvel de Servio (SLAs), mas isso
no significa que se voc no faz o backup do log de transaes, voc corre o risco de, eventualmente, enchendo
sua unidade de log.
Se voc tem um banco de dados que est sujeito a pesadas e / ou regular (por exemplo, diariamente) operaes
de insero em massa, e voc est forando o arquivo de dados a ser incrementado em tamanho regularmente,
por pequenas quantidades, ento provvel que o impacto no desempenho ser significativo . Tambm provvel
que o tamanho do seu arquivo de log vai aumentar rapidamente, a menos que voc estiver executando backups de
log de transaes regulares.
Para saber quo significativo impacto que isso pode ter, vamos dar uma olhada em um exemplo. Eu vou criar um
banco de dados chamado All_Books_Ever_Read , com base em um banco de dados modelo padro, e em
seguida, carregar vrios milhes de linhas de dados em uma tabela no banco de dados, enquanto monitora o
crescimento do arquivo e atividade do disco I / O, usando Profiler e PerfMon, respectivamente. Carregando este
volume de dados pode soar como um caso extremo, mas na verdade "peixe pequeno" em comparao com
muitas empresas corporativas, que se acumulam, dispensar e dispersar Terabytes de dados.
Nota: Eu s acontecer de voc possuir um arquivo, Books-Lista.txt , que supostamente contm
uma listagem de todos os livros j lidos por todos no planeta Terra, o que eu vou usar para
preencher a tabela. Surpreendentemente, o arquivo apenas 33 MB. As pessoas simplesmente
no esto lendo muito mais.
O primeiro passo o de criar o All_Books_Ever_Read dados. Os tamanhos iniciais dos dados e arquivos de
log, e as suas caractersticas de crescimento, ser herdada do banco de dados modelo, conforme descrito na
Figura 1. Uma vez eu criei o banco de dados, eu posso verificar os dados iniciais (MDF) e arquivo de log ( FDL) os
tamanhos so cerca de 3 e 2 MB, respectivamente, como mostrado na Figura 2.
Figura 2: Os dados e arquivos de log tamanhos antes da carga de dados.
O prximo passo fazer o backup do banco de dados. importante perceber que, at que eu tenha feito um
backup de banco de dados completo, o arquivo de log no vai agir como um arquivo de log tpico em um conjunto
de dados para o modo de recuperao total. Na verdade, quando no houver um backup completo do banco de
dados, no ainda possvel realizar um backup do log de transaes, neste ponto, como demonstrado na Figura
3.
Figura 3: No possvel log de backup, se nenhum backup completo do banco existe.
At o primeiro backup completo do banco de dados realizada, esta base de dados est agindo como se ele est
em modo de recuperao simples e log de transaes vai ficar truncado regularmente nos postos de controle, de
modo que voc no vai ver o impacto total da carga de dados sobre o tamanho da o arquivo de log.
Com o banco de dados de backup, eu preciso configurar Profiler e PerfMon para que eu possa monitorar a carga
de dados. Para monitorar o comportamento do crescimento auto usando Profiler, simplesmente inici-lo, ligue
para a instncia do SQL Server 2008 que detm a All_Books_Ever_Read banco de dados, e em seguida, criar
um rastreamento para monitorar dados e Log File Auto Grow eventos, como mostrado na Figura 4.
Figura 4: Configurando o SQL Server Profiler para capturar dados e log de crescimento de arquivo.
Tudo que voc tem que fazer ento clicar em "Run".
Em seguida, vou configurar Perfmon (Ferramentas Administrativas | Performance), a fim de monitorar a atividade
do disco I / O. Clique no boto "+" na barra de ferramentas do grfico; Perfmon ir se conectar ao servidor local por
padro. Selecione "Disco fsico" como o objeto de desempenho, como mostrado na Figura 5, e em seguida,
selecione "% Disk Time" como o contador e clique em "Adicionar".
Em seguida, mude para o objeto Disco fsico e selecione a opo "Average Disk Queue Length" e contadores "fila
de disco atual Comprimento". Estas definies iro capturar a quantidade de atividade do disco, a reviso aps a
carga de dados.
Figura 5: disco fsico objeto de desempenho em Perfmon.
Com todos os sistemas de monitoramento de ir, eu estou pronto para carregar uma tabela de pilha chamado
book_list que eu criei no All_Books_Ever_Read banco de dados. O Books-Lista.txt arquivo tem
aproximadamente 58 mil registros, ento eu vou usar a tcnica de arquivo de lote BCP para percorrer o arquivo 50
vezes, e carga de 2,9 milhes de registros no banco de dados:
definido n = 1%
definir i = 1
: Lao
bcp dba_rep .. SQL_Conn em
C: \ escrita \ Simples Discusso Livro \ Ch3 \ Out1.txt "
TABLOCK-n-b 50000-T-h ""
if% i% == goto end% n%
definir / ai = i +1
goto loop
: Fim
Agora hora de comear a carga. Uma espiada no Perfmon, ver Figura 6, mostra a atual ausncia de atividade
antes de executar uma consulta robusto.
Figura 6: atividade em disco Perfmon.
Execuo de Carga ... agora! Por favor no vire (ou criar) a prxima pgina ...!
Desculpe! Eu no pude resistir a referncia Sesame Street para The Monster no final deste livro . De fato, a carga
prossegue com pouco alarde. Imagine que isto est sendo feito no meio da tarde, talvez depois de um grande
almoo, ou, pior, no incio da AM (DBA: M mais provvel) antes de seu segundo gole de caf, com voc alegremente
inconscientes do que est se desenrolando em um de seus servidores. A Figura 7 mostra o BCP maior processo
de insero em execuo.
Figura 7: BCPing dados no All_Books_Ever_Read dados.
Voc pode ver que o processo de grupo correu 50 vezes a uma mdia de 2,5 segundos uma corrida, com um
tempo total de carga de cerca de 2 minutos. Nada mal para 2,9 milhes de registros. Agora, a m notcia: A figura 8
mostra o quanto o crescimento pode ser atribudo diretamente ao processo de carga.
Figura 8: Log milhes de carregamento crescimento do arquivo de registros na tabela.
Nota: Para efeito de comparao, em um teste eu corri sem nunca ter feito o backup do banco de
dados, o arquivo de dados cresceu para mais de 3 GB, mas o arquivo de log cresceu apenas 150
MB.
Tanto o arquivo de dados eo arquivo de log tem crescido a mais de 3GB. O rastreio Profiler, como mostrado na
Figura 9, revela que um total de 3291 Auto Grow eventos ocorreram durante essa carga de dados. Observe
tambm que a durao desses eventos, quando combinados, no desprezvel.
Figura 9: Os dados e log de crescimento de arquivo capturadas com Profiler.
Finalmente, a Figura 10 mostra a sada PERFMON durante a carga. Como voc pode ver, % tempo de disco ,
obviamente, teve uma batida em 44,192%. Isto no horrvel em si; obviamente, os processos de E / S de disco
exigem l e escreve e, porque "Avg Disk Queue Length" saudvel com menos de 3, significa que o disco capaz
de manter-se com as demandas. No entanto, se o disco que est sendo monitorado tem uma DiskTime% de
80%, ou mais, juntamente com uma maior (> 20) Avg Disk Queue Length, em seguida, haver a degradao do
desempenho porque o disco no pode atender a demanda. Consultas ou arquivo ineficiente crescimento podem
ser os culpados.
Figura 10: Monitor de disco Perfmon.
Mdia e atual da fila de disco comprimentos so indicadores de se deve ou no pode existir gargalos no
subsistema de disco. Neste caso, um comprimento mdio da fila de disco de 1.768 no insuportavelmente alto e
indica que, em mdia, menos de dois pedidos foram em fila, espera de processos de E / S, ou ler ou escrever,
para completar no disco.
O que isto tambm me diz que o carregamento de 2,9 milhes de registros em uma tabela pilha, dosagem ou
cometer cada 50.000 registros, e usando os padres do banco de dados modelo, vai causar I significativa / O lag,
resultando no apenas de carregar os dados, mas tambm da necessidade de crescer os dados e arquivos de
log de alguns milhares de vezes.
Alm disso, com tanta atividade, o banco de dados suscetvel a inabalvel crescimento do arquivo de log, a
menos que voc executar backups de log regulares para remover as entradas de log inativos a partir do arquivo de
log. Muitos procedimentos de manuteno padro implementar backups completos de bancos de dados recm-
criado, mas nem todos os bancos de dados receber backups do log de transaes. Isso poderia vir at mord-lo,
como o monstro no final deste artigo, se voc esquecer de mudar o modelo de recuperao completa de como
Simples, ou se voc restaurar um banco de dados de outro sistema e, sem querer deixar o banco de dados no
modo de recuperao completa.
Apropriadamente dimensionamento seus dados e arquivos de log
Depois de ter visto o impacto dramtico das operaes de carga a granel, tais no tamanho do arquivo, o que eu
realmente quero saber agora o quanto eu poderia reduzir a carga de I / O, e, portanto, aumentar a velocidade do
processo de carga, se o motor no tivesse para crescer os arquivos de 3291 vezes, em incrementos de 1 MB para
o arquivo de dados, e incrementos de 10% para o arquivo de log.
Para descobrir isso, eu preciso repetir o processo de carga, mas com os dados e arquivos de log j
adequadamente dimensionados para lidar com isso. Eu posso conseguir isso simplesmente truncar a tabela e
fazer o backup do log de transaes. Isso no vai diminuir os dados fsicos ou arquivos de log, mas ele vai liberar
todo o espao dentro deles. Antes de eu fazer isso, d uma olhada no tipo de espao de informao de alocao
que fornecido pelo sp_spaceused embutido procedimento armazenado na Figura 11.
Figura 11: Sada de sp_spaceused para a tabela Book_List carregado.
Como voc pode ver, o Book_List mesa est usando toda 3,3 GB do espao alocado para o banco de dados
para os 2,9 milhes de registros. Agora, basta emitir o TRUNCATE comando.
Truncar a tabela Book_List
E ento reprise sp_spaceused . Os resultados so mostrados na Figura 12.
Figura 12: sp_spaceused aps truncamento.
Voc pode verificar se o arquivo de dados, embora agora "vazio", ainda 3,3 GB de tamanho usando o Shrink File
tarefa no SSMS GUI. Clique direito sobre o banco de dados, e selecione "Tasks | Shrink | Files". Voc pode ver na
Figura 13 que o All_Books_Ever_Read.mdf arquivo ainda de 3,3 GB de tamanho, mas tem 99% de espao livre
disponvel.
O que isto significa para mim como um DBA, sabendo que eu vou carregar os mesmos 2,9 milhes de registros,
que eu no espere que o arquivo de dados ir crescer novamente. A Figura 14 mostra a janela de comando aps a
re-executar o processo de insero em massa BCP, superposta ao traado Profiler resultante.
Figura 13: Espao livre no arquivo de dados aps a declarao da tabela truncada.
Figura 14: arquivo de log mnimo em crescimento, com carga de dados.
Desta vez no houve Auto Crescer eventos para o arquivo de dados, e apenas 20 para o arquivo de log. O efeito
lquido que o tempo mdio para carregar 50.000 registros reduzido de 2,5 segundos para 1,3 segundo. A
economia de tempo de pouco mais de 1 segundo por carga pode no parecer significativo no incio, mas
considerar o caso em que o mesmo processo normalmente leva uma hora. Assim, garantindo log e crescimento
de dados foi controlada, de ter cortado o processo para menos de 30 minutos, e salvou um monte de
processamento de I / O, ao mesmo tempo.
Lidar com problemas de espao
Eu mostrei que ter dados de tamanho de forma incorreta e os arquivos de log e inapropriada Auto crescer
propriedades, ambos herdados do modelo de banco de dados, pode aumentar significativamente a carga de I / O
durante os processos de insero em massa. Eu tambm demonstrou os perigos da inabalvel crescimento do
arquivo de log, a menos que voc altere o modelo de recuperao padro ou executar backups de log regulares.
Mesmo para um banco de dados que est sujeita a to pouco quanto 50 mil transaes por dia, eu vi o arquivo de
log do banco de dados crescer para mais de 220G, ao longo de alguns meses, porque nenhum backups do log
foram tomadas. A razo para isto que, geralmente, no so bases de dados com baixo nvel de SLA, o que
significa que um apoio completo noturno tudo o que necessrio.
Como j salientado anteriormente, a manipulao desses problemas de espao principalmente sobre
planejamento. A DBA precisa:
Corretamente tamanho dos arquivos - se voc sabe que o banco de dados voc est gerenciando pode
esperar um crescimento de 2 Gig por ms, o tamanho do arquivo (s) de dados em 4G, inicialmente, no o
tamanho de 3 MB, que ser o padro do banco de dados modelo.
Definir auto correta crescer propriedades - enquanto o crescimento de 10% para os dados e arquivos de
log podem ser suficientes para bancos de dados de baixa utilizao, normalmente eu definir pelo menos
500 MB para as definies de crescimento auto para os dados e arquivos de log. A menos que eu espero
que haja crescimento de dados extraordinariamente alto, 500 MB representa uma boa taxa de crescimento
mdio, e mantm a utilizao do espao em um nvel administrvel, mas permite o crescimento ao longo
do tempo, sem impacto I / O pesado.
Certifique-se apenas os bancos de dados que precisam de recuperao total esto usando-o - voc vai
determinar isso a partir do negcio e faro parte do SLA para a aplicao e banco de dados. Se a
recuperao point-in-time necessria, verifique se voc tem backups de log regulares tomadas dos
bancos de dados no modo de recuperao completa.
Alternar para o modo de log em massa para operaes de insero em massa - carga a granel uma
prtica comum e, se feito corretamente, ir incorrer crescimento log mnima, enquanto a colher os
benefcios de desempenho de carga a granel traz. No entanto, certifique-se de compreender as
conseqncias de mudar os modelos de recuperao, enquanto os dados de carregamento em massa.
Por exemplo, voc no ser capaz de executar uma recuperao point-in-time para as operaes em
massa.
Se voc no planejar corretamente, ou so simplesmente sujeitos a crescimento do arquivo inesperado e
imprevisvel, o que isso significa para o DBA?
Suponha que um banco de dados foi inadvertidamente definido para a recuperao completa, sem backups de log.
O arquivo de log tem vestido maciamente em tamanho e, em ltima anlise, a unidade vai ficar sem espao. Se
voc tiver sorte o suficiente, como eu estou a ter um sistema de alerta, o problema vai ser pego antes que isso
acontea e eu vou receber um alerta, previsivelmente em 2:30 quando eu ter ido para a cama depois de resolver
uma questo diferente.
O que eu fao em tais situaes, depois de amaldioar a mim mesmo ou outras pessoas inocentes no meu time
para no pegar isso mais cedo, a de emitir a seguinte declarao simples:
<databasename> BACKUP LOG WITH TRUNCATE_ONLY
Esta declarao tem o efeito lquido de remover todas as transaes inativas do arquivo de log que teriam sido
removidos com um backup de log padro.
Em seguida, eu reduzir o arquivo de log atravs do GUI (ou, se no estou muito cansado, com cdigo) e, em
seguida, alterar o modelo de recuperao para simples e voltar para a cama. Fazendo isso ir geralmente
recuperar o espao em disco necessrio para limpar todos os alertas, e garantir que o crescimento no mais log
seguir. Voc pode usar DBCC a encolher fisicamente um de dados ou arquivo de log, como segue:
DBCC SHRINKFILE (filename, target_size)
Muitas das situaes que requerem que voc reduzir um arquivo de log pode ser evitada simplesmente planear
adequadamente e ser diligente e meticuloso em seu processo de instalao , em especial, por ter certeza que o
banco de dados modelo sempre definido como Simples e no modo de recuperao total. Ele s precisa
acontecer com voc uma ou duas vezes. Cito George W. Bush, "Engane-me uma vez ... que vergonha ... que
vergonha ... Engane-me no pode ser enganado novamente.
Tome isso, SQL Server modelo de banco de dados.
ndices e grandes contagens de linha
Todos os DBAs sabem que os ndices so necessrios para o desempenho da consulta de estilo olmpico.
Tambm sabemos que eles tm um preo; e esse preo pago na moeda do espao e do tempo de manuteno.
Por mais que eu desesperadamente anseiam por consultas do desenvolvedor para trabalhar de forma eficiente, o
DBA ainda o gatekeeper dos dados e se sente obrigado a apontar as especificidades de consultas por que vai e
no vai beneficiar os ndices que os desenvolvedores sugerem.
Muitas vezes, essas recomendaes de ndice vm de fontes como o Banco de Dados Orientador de Otimizao
(DTA), de modo que muitas vezes evitam DBAs-los em favor da nossa prpria. Eu no quero parecer alto-minded
sobre este ponto, o meu nariz DBA apontada directamente para cima no ar. No entanto, com ou sem razo, os
DBAs querem controlar os tipos de objetos (triggers, tabelas temporrias, servidores vinculados, e assim por
diante) que so adicionados a seus servidores, e os ndices so apenas um outro tipo de objeto que DBAs tem
que entender, gerenciar e manter .
Eu sou totalmente a favor de um ndice agrupado em quase todas as mesas, apoiado por um volume saudvel de
cobrir ndices no-cluster, mas tambm sei por experincia prpria que os ndices, apesar de toda sua boa, s
ser utilizado quando o cdigo adequado executado que vai tirar proveito deles. Vale sempre a pena explicar para
os desenvolvedores de SQL por suas consultas no executar como eles esperam, com seus ndices propostos.
Nesta seo, eu vou adicionar ndices para o Book_List mesa, a fim de descobrir:
Quanto necessrio espao adicional, a fim de adicionar um ndice agrupado para uma tabela contendo
2,9 milhes de linhas.
Se isso o consumo de espao se justifica, examinando as consultas propostas que pretendem aproveitar
os ndices.
Vamos primeiro comear um "antes" vislumbre de utilizao do espao em nossa Book_List mesa, usando o
sp_spaceused procedimento armazenado, como mostrado na Figura 15. Observe a 8K de tamanho do ndice.
Figura 15: index_size da tabela Book_List.
Antes que eu possa adicionar um ndice clusterizado, eu preciso adicionar uma coluna de identidade, chamada
Read_ID , em que para colocar o ndice agrupado. Adicionando a coluna de identidade , em si, uma tarefa cara
para 2,9 milhes de registros. O cdigo o seguinte:
ALTER TABLE Book_list ADD
Read_ID INT IDENTIDADE
Podemos agora criar o ndice agrupado neste Read_ID coluna, como mostrado na Listagem 1.
USE [All_Books_Ever_Read]
GO
CRIAR UNIQUE CLUSTERED INDEX [Read_ID] ON [dbo] . [Book_List] ( [Read_Date] ASC )
COM (
STATISTICS_NORECOMPUTE = OFF ,
SORT_IN_TEMPDB = OFF ,
IGNORE_DUP_KEY = OFF ,
DROP_EXISTING = OFF ,
ONLINE = OFF ,
ALLOW_ROW_LOCKS = ON ,
ALLOW_PAGE_LOCKS = ON )
ON [PRIMARY]
GO
Listagem 1: Criao de um ndice clusterizado na Read_ID coluna da Book_List mesa.
Como voc pode ver na Figura 16, a construo de um ndice clusterizado em quase 3 milhes de discos leva
algum tempo e poder de processamento.
Figura 16: Demora mais de 12 minutos para construir o ndice agrupado.
Alm disso, deve-se notar que os usurios no sero capazes de se conectar Book_List mesa para a
durao da construo de ndice. Essencialmente, o SQL Server tem de ordenar fisicamente os milhes de
registros para se alinhar com a definio do ndice clusterizado.
Vamos ver o que o ndice tirou da minha pele por meio do espao. O primeiro espao de ndice para esta tabela foi
8K e espao de dados foi mais de 3 Gig. O que sp_spaceused me dizer agora? Ver Figura 17.
Figura 17: Construindo o ndice agrupado aumentou o index_size para 5376KB.
Um aumento na index_size para 5376K no parece muito significativo. Quando voc cria um ndice
clusterizado, o motor de banco de dados pega os dados no heap (tabela) e classifica-lo fisicamente. Em termos
mais simples, tanto uma pilha e uma mesa de cluster (uma tabela com um ndice de cluster), tanto armazenar os
dados reais, apenas ordenados fisicamente. Ento, eu no esperaria que a adio de um ndice de cluster para
o Read_ID coluna para causar muito crescimento em index_size .
No entanto, enquanto o tamanho dos dados e tamanho de ndice para o Book_List mesa no cresceu
significativamente, o espao alocado para o banco de dados fez dupla, como voc pode ver na Figura 18.
Figura 18: Criando o ndice agrupado causou o arquivo de dados para dobrar de tamanho.
Assim, no s a adio ndice tirar a tabela off-line para a durao da construo, a 12 minutos, tambm dobrou o
espao em disco. A razo para o crescimento que o SQL Server tinha que fazer todo o tipo de processamento
para reorganizar os dados de uma pilha a uma tabela de cluster e de espao adicional, quase o dobro, foi
necessria para acomodar essa migrao de uma tabela heap para uma tabela em cluster. Observe, porm, que,
aps o processo foi concludo h cerca de 50% de espao livre no arquivo expandido.
A questo permanece, eu beneficiar da adio deste ndice, e que eu preciso adicionar qualquer cobrindo ndices
no-cluster? Primeiro, vamos considerar a consulta simples mostrado na Listagem 2. Ele retorna dados com base
em um intervalo especificado de Read_ID valores (eu sei que tenho uma srie de dados entre 1 e 2.902.000
registros).
Selecione book_list . Read_ID ,
book_list . Read_Date ,
book_list . Livro ,
book_list . Pessoa
de book_list
Onde Read_Id entre 756000 e 820000
Listagem 2: A consulta a Read_ID coluna.
Esta consulta retornou 64.001 registros em 2 segundos, que, primeira vista, parece ser o tipo de desempenho
que eu esperava. No entanto, para confirmar isso, eu preciso examinar o plano de execuo, como mostrado na
Figura 19. / P>
Figura 19: uso benfico de ndice de cluster para a tabela Book_list.
Voc pode ver que um Index Seek operao foi utilizado, o que indica que este ndice tem, efectivamente, servido
bem a nossa consulta. Isso significa que o motor foi capaz de recuperar todos os dados necessrios com base
unicamente nos valores-chave armazenadas no ndice. Se, em vez disso, eu tinha visto uma varredura de ndice,
isto indicaria que o motor decidiu escanear cada linha nica do ndice, a fim de recuperar as necessrias. Uma
varredura de ndice semelhante em conceito a um exame de tabela e ambos so geralmente ineficazes,
especialmente quando se lida com esses grandes conjuntos de registros. No entanto, o mecanismo de consulta,
s vezes, optar por fazer uma varredura mesmo se um ndice utilizvel est no lugar, se, por exemplo, uma
percentagem elevada das linhas precisam ser devolvidos. Isso muitas vezes um indicador de um ineficiente
ONDE clusula.>
Vamos dizer que eu agora deseja consultar um campo que no est includo no ndice de cluster, como o
Read_Date . Eu gostaria de saber quantos livros foram lidos em 24 de julho de 2008. A consulta seria algo
parecido com o mostrado na Listagem 3.
Selecione contagem ( book_list . Read_ID ),
book_list . Read_Date
de book_list
onde book_list . Read_Date entre '07 / 24/2008 00:00:00 '
e '07 / 24/2008 11:59:59 '
Grupo por book_list . Read_Date
Listagem 3: Uma consulta que no coberto pelo ndice agrupado.
A execuo dessa consulta, e aguarda os resultados para voltar, um pouco como ver tinta secar ou, algo que eu
gostaria de fazer com freqncia, observando uma desfragmentao de disco rgido. Demorou um minuto e 28
segundos para completar, e retornou 123 registros, com uma contagem mdia do nmero de livros lidos em
7/24/2008 de 1000.
O plano de execuo para esta consulta, no surpreendentemente, mostra que a varredura do ndice foi utilizado,
como voc pode ver na Figura 20.
Figura 20: verificao de ndice clusterizado para campo com nenhum ndice.
O que foi um pouco surpreendente, porm, que a alocao de memria para o SQL Server disparou atravs do
telhado como esta consulta foi executada. A Figura 21 mostra o consumo de memria em 2,51 g que muito
drstica, considerando o sistema s tem 2G de memria RAM.
Figura 21: Utilizao de memria resultante da consulta intervalo de datas.
A razo para o aumento de memria que, j que no houve ndice disponvel para limitar os dados para a
consulta, o SQL Server tinha que carregar vrios milhes de registros no cache de buffer, a fim de me devolver as
123 linhas que eu precisava. A menos que voc tenha habilitado AWE e memria mxima do servidor definido para
2G (digamos) menos do que a memria total do servidor, o servidor vai comear a paginao, como SQL Server
pega mais do que seu quinho de memria e discos debulhando. Isto ter um impacto significativo sobre o
desempenho.
Se h uma coisa que eu sei com certeza no que diz respeito configurao do SQL Server e gerenciamento, que
uma vez que o SQL Server adquiriu memria, ele no gosta de dar-lhe de volta para o sistema operacional a no
ser estimulada a faz-lo. Mesmo que a consulta Corri completou muitos minutos atrs, minha instncia do SQL
Server ainda paira em 2.5G de memria usada, a maior parte pelo SQL Server.
claro que eu preciso para criar ndices que iro cobrir as consultas que eu preciso para ser executado, e assim
evitar SQL Server fazer tal uma varredura de ndice caro. Eu sei que isso nem sempre possvel em um ambiente
de produo, com muitas equipes de desenvolvedores de todo escrevendo suas prprias consultas em seu
prprio estilo, mas no meu ambiente isolado um objetivo atingvel.
A primeira coisa que precisa fazer reiniciar o SQL Server para voltar a um nvel razovel de utilizao da memria.
Embora existam outros mtodos para reduzir o consumo de memria, tais como liberar o cache de buffer ( DBCC
DROPCLEANBUFFERS ), tenho o luxo de um ambiente isolado e reiniciar o SQL Server vai me dar um "comeo
limpo" para a soluo de problemas. Tendo feito isso, eu posso adicionar dois ndices no-cluster, um que ir
abranger consultas sobre o Livro campo eo outro o Read_Date campo.
Tendo criado os dois novos ndices, vamos dar um outro olhar para a utilizao do espao no Book_List mesa,
usando sp_spaceused, como mostrado na Figura 22.

Figura 22: Aumento do tamanho do ndice para 2 ndices no clusterizados.
O index_size subiu de 5MB de 119MB, o que parece bastante mnimo, e um excelente trade-off assumindo que
ter o impulso esperado no desempenho da read_date consulta.
Se voc um DBA, trabalhando ao lado de desenvolvedores que lhe do suas consultas para anlise, este o
lugar onde voc prende a respirao. Respirao presa, eu clico executar. E ... a consulta foi de 1 minuto 28
segundo para 2 segundos sem arroto mesmo um beb em memria do SQL Server. O novo plano de execuo,
mostrado na Figura 23, conta a histria completa.
Figura 23: Adio de cobertura ndices leva a um ndice eficiente operao de busca.
Assim, enquanto ndices de fato ter o espao, esta utilizao do espao geralmente mais do que justificada
quando eles so usados corretamente, e vemos o pay-off desejado no desempenho da consulta.>
O problema com ndices surge quando as equipes de desenvolvimento adoptar uma abordagem scattergun a
ndices, s vezes ao ponto de redundncia e danos ao banco de dados. Adicionando ndices arbitrariamente
muitas vezes pode fazer tanto mal quanto bem, no s por causa do espao que eles ocupam, mas porque cada
ndice ter de ser mantida, o que leva tempo e recursos. / P>
TempDB
No DBA que trabalha com o SQL Server por muito tempo ter sido imune a fugir crescimento tempdb. Se esse
crescimento se no for controlada, pode eventualmente encher uma unidade e proibir qualquer nova atividade no
SQL Server, que tambm requer o uso do banco de dados tempdb.
SQL Server usa o banco de dados tempdb para uma srie de processos, como a classificao de operaes,
criao de ndices, cursores, variveis de tabela de banco de dados, e-mail e funes definidas pelo usurio, para
citar alguns. Alm de processos internos, os usurios tm a capacidade de criar tabelas temporrias e tm total
liberdade para preencher essas tabelas com dados, tanto quanto eles querem, assumindo que o crescimento do
arquivo de dados tempdb no se restringe a um valor especfico, que por padro ele no .
Eu no recomendo a restrio de crescimento para tempdb, mas eu recomendo que voc esteja ciente do que vai
acontecer se tempdb no encher. Muitos processos do SQL Server, incluindo os processos de usurio, e deixar
uma mensagem de erro ser lanada, como vou mostrar.
O banco de dados tempdb criado toda vez que o SQL Server reiniciado. Nunca apoiada nem pode ser.
sempre em modo simples e o modelo de recuperao no pode ser mudado.
H um par de TempDB "Propriedades", no entanto, que voc pode e deve mudar quando a configurao de seu
servidor:
A sua localizao
Sua taxa de aumento automtico
Por padro, o tempdb criado na pasta de dados padro, que definido durante a instalao do SQL. altamente
recomendado que, se possvel, esta localizao ser alterada para que TempDB reside em seu prprio disco.
Muitos DBAs tambm criar vrios arquivos tempdb, normalmente um por processador, com o objetivo de
impulsionar o desempenho ainda mais. No entanto, alertou que ser necessrio distribuir a carga desses vrios
arquivos em vrios discos, a fim de alcanar este objectivo.
Como todos os outros bancos de dados, TempDB adota a configurao padro do banco de dados modelo, o que
significa que ele ir crescer em incrementos de 10%, com crescimento irrestrito, a menos que voc especifique o
contrrio. Na minha opinio, ter um aumento automtico de 10% sobre o tempdb uma m idia, porque quando
as consultas desonestos bater seu servidor, chamando para tabelas temporrias, como eles vo fazer,
eventualmente, voc no quer que o banco de dados tempdb encher a unidade. Vamos supor que voc tem um
banco de dados de 30G TempDB sentado em uma unidade de 50G e crescimento automtico em 10% (ou seja,
3G) incrementos. Levaria apenas 6 eventos de crescimento para encher o carro. Idealmente, voc vai querer definir
uma taxa de crescimento fixa de 3G para TempDB e usar vrios arquivos de dados tempdb em vrios discos.
Ao carregar vrias dezenas de milhes de registros em tempdb, tendo em conta que 1 milho de registros
aproximadamente equivalente a 1G, voc pode ver como isso pode acontecer facilmente. Ento, o que acontece
quando TempDB enche? Vamos descobrir!
Eu teria que gerar um monte de atividade TempDB para encher 50 GB de disco, por isso estou indo para restringir
artificialmente o arquivo de dados para tempdb para um tamanho de 200 MB, atravs da propriedade "tamanho
mximo do arquivo." A Figura 24 mostra a configurao.
Figura 24: Alterar o tamanho mximo de arquivo TempDB 2 Gigabytes para simulao.
Agora que eu definir o tamanho mximo de arquivo para tempdb, hora de preench-lo e para que eu me voltarei
para o nosso velho amigo, o loop infinito. Eu s vi alguns deles em estado selvagem, mas elas existem, eu
prometo, e quando voc combina um loop infinito com dados ou de log limitao de espao, algo tem que dar. A
Listagem 4 mostra o cdigo maluco.
CREATE TABLE # Holdall
(
Read_ID INT ,
Read_Date DATETIME ,
Pessoa varchar (100)
)
GO
DECLARE @ cnt int = 1
ENQUANTO @ cnt = 1
Incio

INSERIR NO # Holdall
SELECIONE Read_ID ,
Read_Date ,
Pessoa
DE All_Books_Ever_Read . dbo . book_List
ONDE Read_Date > '05 / 21/08 '
Fim
GO
Listagem 4: O loop infinito temido.
Observe que @ cnt dado o valor de 1, mas em nenhum lugar, posteriormente, o valor alterado, para esta
consulta vai correr e correr at que ele enche uma unidade ou ultrapassa um limite de tamanho de arquivo, o que
ocorrer mais cedo. Neste exemplo, a consulta executada por 3 minutos antes de bater o limite de tamanho de
arquivo de 200 MB, conforme mostrado na Figura 25, e recebo um erro que o grupo de arquivos est cheio.
Figura 25: Enchendo tempdb.
Neste ponto, a consulta falhar, obviamente, assim como quaisquer outras questes que precisam usar tempdb.
SQL Server ainda est funcionando corretamente, mas enquanto a tabela temporria # Holdall existe, TempDB
vai ficar cheia.
Felizmente, voc tem notificaes e alertas criados para avis-lo do perigo iminente, antes que o arquivo realmente
enche. Em qualquer caso, voc provvel que a experincia que DBA: M sentimento, depois de ter passado
metade da noite tentando rastrear a consulta problema e resolver o problema.
Nota: eu cubro notificaes, alertas e monitoramento em profundidade no Captulo 6 de meu livro,
SQL Server Tacklebox , do qual este artigo foi extrado e que est disponvel em forma de e-book
para download gratuito.
Seus trs opes, como DBA, so:
Reinicie o SQL Server.
Tente diminuir o banco de dados tempdb.
Encontre a consulta errante e erradic-la.
De modo geral, reiniciando nem sempre uma opo em um sistema de produo. Reduzindo tempdb uma
opo vlida, supondo que ela pode ser reduzida. Algumas vezes, quando existem operaes abertas, no
possvel. Portanto, encontrar e matar a consulta agressor o curso mais provvel de ao. As tcnicas que voc
pode usar para fazer isso so o foco do meu artigo sobre a soluo de problemas .
Por enquanto, eu vou simplesmente fechar a janela de consulta que deve forar a tabela temporria a ser
eliminado e assim permitir que a operao de reduo de ir em frente. Com certeza, uma vez que eu tinha fechado
a conexo que eu era capaz de selecionar Tasks | Shrink | Banco de Dados a partir do SSMS, e assim diminuir
TempDB de 200 MB de volta ao seu tamanho original de 8K. Problema resolvido.
Agora, de volta para a cama com uma nota sonolento para si mesmo para encontrar o desenvolvedor que escreveu
este cdigo, e castig-lo ou ela. Espere, eu sou o DBA que deixar isso entrar em produo no primeiro lugar, para
castigar nova lista ... eu, voltar a dormir, encontrar o desenvolvedor amanh e castig-lo ou dela de qualquer
maneira; se perguntar como ele chegou em produo ... mudar de assunto.
A consulta para determinar a utilizao do espao atual
Tenho escrito alguns artigos sobre vrias consultas que me ajudam com o meu dia-a-dia de trabalho como um
DBA. A consulta a seguir aquele que eu uso todos os dias para monitorar problemas de espao em potencial
sobre os meus servidores. Se eu notar um "sinal de perigo" Posso, ento, cavar mais fundo e determinar a causa
raiz, que normalmente uma das questes discutidas neste artigo ou seja, o crescimento do arquivo de log devido
a modelos errados de recuperao, muitos ndices, TempDB enchendo, ou apenas planejamento fraca
capacidade.
O SizeQuery consulta, mostrado na Listagem 5, combina a sada de vrias fontes, tais como
sp_MSForEachDB e xp_fixeddrives , e mescla-los para mostrar a quantidade de dados e log espao
usado, o que conduzir esse espao usado, e quanto espao livre est disponvel .
Definir NoCount On
- Verifique a tabela temporria existe
SE EXISTE ( SELECIONAR Nome
DE tempdb .. sysobjects
Onde nome como '# HoldforEachDB%' )
- Se Ento Drop it
GOTA TABLE # HoldforEachDB_size
- Recri-lo
CRIAR TABELA # HoldforEachDB_size
(
[DatabaseName] [nvarchar] ( 75 ) COLLATE SQL_Latin1_General_CP1_CI_AS
NOT NULL,
[Tamanho] [decimal] NO NULL,
[Nome] [nvarchar] ( 75 ) COLLATE SQL_Latin1_General_CP1_CI_AS
NOT NULL,
[Nome do arquivo] [nvarchar] ( 255 ) COLLATE SQL_Latin1_General_CP1_CI_AS
NOT NULL,

)
ON [PRIMARY]

SE EXISTE ( SELECIONAR nome
DE tempdb .. sysobjects
Onde nome como '# fixed_drives%' )
- Se Ento Drop it
GOTA DE MESA # fixed_drives
- Recri-lo
CRIAR TABELA # fixed_drives
(
[Drive] [caractere] ( 1 ) COLLATE SQL_Latin1_General_CP1_CI_AS
NOT NULL,
[MBFree] [decimal] NO NULL
)
ON [PRIMARY]
- Inserir linhas de sp_MSForEachDB em tabela temporria
INSERIR NO # HoldforEachDB_size
EXEC sp_MSForEachDB 'Select''?'' como DatabaseName, Caso Quando [?] ..
sysfiles.size * 8/1024 = 0 Then 1 Else [?] .. sysfiles.size * 8/1024 Fim
Como tamanho, [?] .. Sysfiles.name,
[?] .. Sysfiles.filename De [?] .. Sysfiles '
- Selecione todas as linhas da tabela temporria (tabela temporria ser auto excluir
quando a conexo est desaparecido.

INSERIR NO # fixed_drives
EXEC xp_fixeddrives

Selecione @ @ servername
imprimir '' ;
Selecione rtrim ( Cast ( DatabaseName as varchar ( 75 ))) as DatabaseName ,
Dirija ,
Matrcula ,
Fundido ( Tamanho como int ) AS Tamanho ,
Fundido ( MBFree como varchar ( 10 )) como MB_Free
de # HoldforEachDB_size
INNER Cadastre # fixed_drives NA ESQUERDA ( # HoldforEachDB_size . Matrcula , 1
) = # fixed_drives . Unidade
GROUP BY DatabaseName ,
Dirija ,
MBFree ,
Matrcula ,
Fundido ( Tamanho como int )
ORDER BY unidade ,
Tamanho Desc
imprimir '' ;
Selecione rgido como [Espao Total Dados Usado |] ,
Cast(Sum(Size) as varchar(10)) as [Total Size],
Fundido ( MBFree como varchar ( 10 )) como MB_Free
INNER Cadastre # fixed_drives NA ESQUERDA ( # HoldforEachDB_size . Matrcula , 1
) = # fixed_drives . Unidade
Grupo pela Unidade ,
MBFree
imprimir '' ;
Select count ( DISTINCT rtrim ( Cast ( DatabaseName as varchar ( 75 )))) as
Database_Count
Listagem 5: consulta Size.
Exemplos de resultados a consulta de tamanho esto apresentados na Figura 26.
Figura 26: Sada de consulta Size.
Voc pode ver que o All_Books_Ever_Read banco de dados tem 6,4 g de espao alocado no C: unidade.
Desde meus bancos de dados de amostra residem apenas no C: dirigir, tudo alocao para esta unidade. No
entanto, se eu tenho os meus arquivos de log on E: e TempDB em F: , por exemplo, em seguida, consulta sada
mostraria a quebra para cada unidade que realmente armazena qualquer arquivo de banco de dados. Voc pode
ver que h 61G livre no C: conduzir e de 11G que consiste em arquivos de banco de dados.
Resumo
Neste artigo, eu tenho explorado alguns dos cenrios onde o espao em disco consumido por processos, em
muitos casos, por causa de configuraes incorretas de modelos de recuperao, o crescimento de dados para
objetos grandes e consultas que sobrecarregam os recursos tempdb. Muitos desses cenrios pode ser evitado
com um planejamento adequado. No entanto, pode-se esperar que, em algum momento, ir surgir uma situao
que requer a equipe DBA para entrar e resgatar o SQL Server.
Quando isso acontece, e isso acontece com bastante freqncia, os DBAs precisa ter um arsenal de ferramentas
de resoluo de problemas sua disposio.
Obrigado por compartilhar este autor: 1
Este artigo retirado do captulo 4 de seu livro, o SQL Server Tacklebox. Voc pode comprar uma
cpia do livro de Amazon.com , ou, se voc assinante, faa o download de um e-cpia gratuita do
Simple-Talk . Se voc gostou deste captulo, ento voc vai gostar destes artigos de Rodney
tambm tomadas do livro ... Comer instalaes do SQL Server para o pequeno almoo Dados
Finding Corrupo A DBA como Detective: Locking Soluo de problemas e bloqueio

Este artigo foi visto 60.579 vezes.
Autor perfil: Rodney Landrum
Rodney Landrum foi arquitetar solues para SQL Server h mais de 10 anos. Ele j trabalhou com e
escrito sobre muitas tecnologias SQL Server, incluindo DTS, Integration Services, Analysis Services e
Reporting Services. Ele autor de trs livros sobre o Reporting Services, incluindo a sua mais
recente edio de 2008 para Apress. Ele um colaborador regular da revista SQL Server e Simple-
talk.com, onde ele bloga sobre coisas como aranhas, cerveja, somnambulance e SQL. Seus trs
artigos recentes na revista SQL Server sobre a construo de um repositrio DBA com SSIS e SSRS foram bem
recebidos e implementados amplamente por DBAs ao redor do mundo. Rodney tambm fala regularmente sobre
temas SQL em eventos como SQL sbado eo SQL Server usurios Pensacola Group. Seu dia de trabalho
encontra-lo supervisionar a sade eo bem-estar de mais de 100 servidores SQL como gerente de administrao
de banco de dados em Pensacola, Florida.
Buscar por outros artigos por Rodney Landrum
Classifique este artigo: Avaliao Mdia: de um total de 100 votos.
Pobre Est bem Bom Grande Deve l er
D a sua opinio
Voc tem uma opinio sobre este artigo? Em seguida, adicionar o seu comentrio abaixo :
Voc deve estar logado para postar neste frum Clique aqui para efetuar login .
Assunto: Grande
Postado por: michaeltocik ( vista de perfil )
Postado em: Sbado, 23 de janeiro, 2010 s 14:32
Mensagem: Muito bem escrito, como j se acostumar com este site.
Assunto: Incrvel!
Postado por: Gabriel ( no assinado em )
Postado em: Segunda-feira, 25 de janeiro, 2010 s 02:50
Mensagem: S quando eu estava me perguntando algumas das melhores
prticas para o crescimento de dados ... eu achei isso na minha
caixa de entrada! O que eu li at agora inegavelmente til. Mal
posso esperar para l-lo na sua totalidade.
Assunto: Recursos Compartilhados do local do diretrio ..
Postado por: Luctor "Ed" Emergo ( vista de perfil )
Partilhar Compartilhar Compartilhar
Sobre Mapa do site Torne-se um autor Newsletters
Entre em contato conosco Ajudar
Poltica de Privacidade Termos e Condies 2005-2014 Red Gate Software
Postado em: Segunda-feira abril 12, 2010 em 04:53
Mensagem: Oi senhor Landrum, Rodney, estou a instalar o SQL Server 2008 e
eu estou querendo saber sobre a localizao do diretrio "Recurso
Partilhado". A nossa organizao tem uma corrida de instalao do
SQL 2005, que instalado com tudo na unidade c: \, e eu no quero
nenhum DBA: M mais. Voc sabe se esses recursos
compartilhados, como Integration Services log coisas? Eu no quero
nada disso em c: \ mais, nunca. Tenho registros e unidade de dados
agora, mas onde colocar isso? O artigo maravilhoso, embora eu
realmente no sei como nossos aplicativos esto usando SQL no
momento. Vou discutir isso com os nossos desenvolvedores. Groet!
Rick
Assunto: 80% Citao
Postado por: smoore4 ( vista de perfil )
Postado em: Quinta - feira, 29 maro, 2012 s 10:45
Mensagem: Acabei de ver uma apresentao IBM citar uma linha a partir deste
artigo, e eu tenho que questionar a premissa da citao abaixo (1
pargrafo). 80% s no se sustenta. Eu no gasto 80% do meu
tempo com questes relacionadas ao disco. Nem perto disso. "No
geral, eu estimaria que tais questes so responsveis por cerca de
80% dos problemas que a equipe enfrenta DBA em uma base
semanal."
Assunto: Nota da Gratido
Postado por: gsrikar33 ( vista de perfil )
Postado em: Tera - feira, 4 de maro, 2014 s 01:04
Mensagem: Muito obrigado por ter escrito isso .. til para todos os DBA Junior.
Eu tambm tenho "SQL Server caixa de equipamento" livro escrito
por voc. Sou muito grato a voc.
Hats off ..!

Gerenciando o Crescimento de Dados No SQL Server

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerenciando o Crescimento de Dados No SQL Server

Enviado por

Direitos autorais:

Formatos disponíveis

15/7/2014 Gerenciando o crescimento de dados no SQL Server

Você também pode gostar