Neste artigo, vamos rever os erros dos DBAs, cujas consequências foram bastante perceptíveis e com os quais tive que lidar.
O objetivo do artigo é evitar que os usuários repitam esses erros. Às vezes, uma experiência ruim é ainda mais valiosa do que uma positiva.
- Percentual de incremento de arquivos de banco de dados
Como o crescimento de arquivos do banco de dados é uma operação que consome muitos recursos, pode parecer que definir esse crescimento em proporções percentuais pode ser uma boa ideia. Concordo que muitas diretrizes recomendam definir um incremento fixo em MB, em vez de percentual. No entanto, eles não explicam os motivos. Com base na prática, não é recomendado definir o incremento de um arquivo de banco de dados acima de 1 GB, pois o MS SQL Server alocará 1 GB 2 vezes em vez de 2 GB de uma vez.
Além disso, se você alocar menos de 32 MB , mais cedo ou mais tarde o banco de dados simplesmente ficará mais lento. Portanto, é melhor definir um incremento fixo nos arquivos de banco de dados de 32 a 1024 MB. No entanto, por que é impossível especificar o incremento de arquivos de banco de dados como uma porcentagem? Acontece que assim que o arquivo tiver menos de 1 MB, o DBMS arredonda esse valor para 0 MB e para de aumentar esse arquivo. Como resultado, o sistema está inoperante. Para saber o quanto precisamos aumentar o arquivo, basta realizar uma análise diária para verificar quanto cada arquivo ganha em MB e definir o número adequado na faixa de 32 a 1024 MB. Podemos coletar estatísticas sobre o crescimento dos arquivos de banco de dados da seguinte maneira. - Existem muitas chaves estrangeiras para uma tabela
Você já tentou verificar o plano ao excluir pelo menos uma linha de uma tabela referenciada por quase centenas de outras tabelas? Você ficará surpreso ao saber quantos loops aninhados existem. Todos eles são verificações de chave estrangeira. Por isso, se as tabelas forem grandes (mais de um milhão de registros), é melhor desabilitar as chaves estrangeiras de uma tabela na qual os dados serão excluídos. Em seguida, você precisará excluir todos os dados necessários e relacionados. Depois disso, habilite as chaves estrangeiras. Uma situação semelhante ocorre com atualizações e exclusões em cascata. Se houver muitos links externos (centenas), a exclusão de uma única linha pode levar a um bloqueio longo e muito extenso. - Muitos índices desnecessários
Muitas vezes, você pode ver nas diretrizes que ao criar chaves estrangeiras, é necessário construir índices, especialmente ao usar essas chaves para junções. Você precisa verificar se os índices são usados, caso contrário, esses índices desnecessários apenas retardarão as operações de modificação de dados. Para verificar isso, use a seguinte consulta:
select DB_NAME(t.database_id) as [DBName] , SCHEMA_NAME(obj.schema_id) as [SchemaName] , OBJECT_NAME(t.object_id) as [ObjectName] , obj.Type as [ObjectType] , obj.Type_Desc as [ObjectTypeDesc] , ind.name as [IndexName] , ind.Type as IndexType , ind.Type_Desc as IndexTypeDesc , ind.Is_Unique as IndexIsUnique , ind.is_primary_key as IndexIsPK , ind.is_unique_constraint as IndexIsUniqueConstraint , t.[Database_ID] , t.[Object_ID] , t.[Index_ID] , t.Last_User_Seek , t.Last_User_Scan , t.Last_User_Lookup , t.Last_System_Seek , t.Last_System_Scan , t.Last_System_Lookup from sys.dm_db_index_usage_stats as t inner join sys.objects as obj on t.[object_id]=obj.[object_id] inner join sys.indexes as ind on t.[object_id]=ind.[object_id] and t.index_id=ind.index_id where (last_user_seek is null or last_user_seek <dateadd(year,-1,getdate())) and (last_user_scan is null or last_user_scan <dateadd(year,-1,getdate())) and (last_user_lookup is null or last_user_lookup <dateadd(year,-1,getdate())) and (last_system_seek is null or last_system_seek <dateadd(year,-1,getdate())) and (last_system_scan is null or last_system_scan <dateadd(year,-1,getdate())) and (last_system_lookup is null or last_system_lookup <dateadd(year,-1,getdate())) and t.database_id>4 and t.[object_id]>0 -- system databases are excluded
- Uso ineficiente de recursos
Geralmente, é recomendável armazenar o log de transações e o arquivo de banco de dados em diferentes dispositivos de armazenamento. Se você usa o RAID 10 com 4 e mais discos SSD, não faz sentido isolar os arquivos uns dos outros. Para uma velocidade mais alta, se necessário, o banco de dados tempdb pode ser armazenado em um disco separado da RAM. Além disso, grandes quantidades de RAM fornecidas ao DBMS farão com que este preencha toda a memória com planos de consulta irrelevantes. - Backups ruins
É sempre necessário não apenas verificar os backups criados, mas também movê-los em uma bancada de teste e restaurá-los. Tudo isso precisa ser automatizado com notificações adicionais aos administradores sobre recuperações problemáticas e bem-sucedidas. - Baixa tolerância a falhas
Antes de fazer um cluster de dois ou mais servidores, você precisa ter certeza de que o sistema de armazenamento de dados também é tolerante a falhas. Se o último falhar, toda a tolerância a falhas será reduzida a zero. - Complicado diagnóstico sem verificações simples
Se houver um tempo de inatividade do sistema, primeiro você precisa verificar os logs do MS SQL Server e depois ir mais fundo. Você deve primeiro realizar verificações simples e, em seguida, proceder a um diagnóstico complexo. - Mesas perdidas
As tabelas podem ser estendidas com dados desnecessários que precisam ser arquivados em um banco de dados separado ou excluídos. Além disso, as tabelas não podem mais ser usadas.
Estas são as situações com as quais me deparei. Portanto, gostaria de recomendar não repetir os erros acima.
Você gostaria de compartilhar sua experiência ou tais erros ao administrar bancos de dados, sinta-se à vontade para me informar - ficarei feliz em discuti-los.
