In questo articolo esamineremo gli errori dei DBA, le cui conseguenze erano abbastanza percettibili e che ho dovuto affrontare.
Lo scopo dell'articolo è impedire agli utenti di ripetere questi errori. A volte, una brutta esperienza è ancora più preziosa di una positiva.
- Incremento percentuale dei file di database
Dato che la crescita dei file del database è un'operazione che richiede molte risorse, può sembrare che impostare questa crescita nei rapporti percentuali possa essere una buona idea. Sono d'accordo sul fatto che molte linee guida consigliano di impostare un incremento fisso in MB, anziché percentuale. Tuttavia, non spiegano le ragioni. In base alla pratica, non è consigliabile impostare l'incremento di un file di database superiore a 1 GB, poiché MS SQL Server allocherà 1 GB 2 volte anziché 2 GB alla volta.
Inoltre, se si allocano meno di 32 MB , prima o poi il database rallenterà semplicemente. Quindi, è meglio impostare un incremento fisso sui file di database da 32 a 1024 MB. Tuttavia, perché è impossibile specificare l'incremento dei file di database come percentuale? Si scopre che non appena il file è inferiore a 1 MB, il DBMS arrotonda questo valore a 0 MB e smette di aumentare questo file. Di conseguenza, il sistema è inattivo. Per scoprire di quanto dobbiamo aumentare il file, è sufficiente eseguire un'analisi giornaliera in modo da verificare quanto guadagna in MB ogni file e impostare il numero appropriato nell'intervallo da 32 a 1024 MB. Possiamo raccogliere statistiche sulla crescita dei file di database nel modo seguente. - Ci sono molte chiavi esterne per una tabella
Hai mai provato a controllare il piano quando elimini almeno una riga da una tabella a cui fanno riferimento quasi centinaia di altre tabelle? Sarai sorpreso di sapere quanti loop nidificati ci sono. Sono tutti controlli di chiavi esterne. Ecco perché se le tabelle sono grandi (oltre un milione di record), è meglio disabilitare le chiavi esterne per una tabella in cui i dati verranno eliminati. Quindi, dovrai eliminare tutti i dati necessari e relativi. Successivamente, abilita le chiavi esterne. Una situazione simile si verifica con aggiornamenti ed eliminazioni a cascata. Se sono presenti molti link esterni (centinaia), l'eliminazione anche di una sola riga può comportare un blocco lungo e molto esteso. - Tanti indici inutili
Molto spesso, puoi vedere nelle linee guida che durante la creazione di chiavi esterne, è necessario creare indici, specialmente quando si utilizzano queste chiavi per i join. È necessario verificare che gli indici vengano utilizzati, altrimenti questi indici inutili rallenteranno solo le operazioni di modifica dei dati. Per verificarlo, utilizza la seguente query: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 inefficiente delle risorse
Si consiglia spesso di archiviare il registro delle transazioni e il file di database su dispositivi di archiviazione diversi. Se utilizzi RAID 10 con 4 e più dischi SSD, non ha senso isolare i file l'uno dall'altro. Per una maggiore velocità, se necessario, il database tempdb può essere archiviato su un disco diviso dalla RAM. Inoltre, una quantità eccessiva di RAM fornita al DBMS farà sì che quest'ultimo riempia tutta la memoria con piani di query irrilevanti. - Backup errati
È sempre necessario non solo controllare i backup creati ma anche spostarli su un banco prova e ripristinarli. Tutto questo deve essere automatizzato con un'ulteriore notifica agli amministratori di recuperi problematici e riusciti. - Cattiva tolleranza ai guasti
Prima di creare un cluster di due o più server, è necessario assicurarsi che anche il sistema di archiviazione dati sia a tolleranza di errore. Se quest'ultimo fallisce, l'intera tolleranza di errore verrà ridotta a zero. - Complicato diagnostica senza semplici controlli
Se si verifica un tempo di inattività del sistema, è innanzitutto necessario controllare i registri di MS SQL Server e quindi approfondire. Dovresti prima eseguire semplici controlli e poi procedere a una diagnostica complessa. - Tabelle perse
Le tabelle possono essere estese con dati non necessari che devono essere archiviati in un database separato o eliminati. Inoltre, le tabelle potrebbero non essere più utilizzate.
Queste sono le situazioni in cui mi sono imbattuto. Pertanto, vorrei raccomandare di non ripetere gli errori di cui sopra.
Vorresti condividere la tua esperienza o errori simili durante l'amministrazione dei database, sentiti libero di farmelo sapere:sarò felice di discuterne.
