В тази статия ще прегледаме грешките на DBA, чиито последици бяха доста осезаеми и с които трябваше да се справя.
Целта на статията е да попречи на потребителите да повтарят тези грешки. Понякога лошият опит е дори по-ценен от положителния.
- Процентно увеличение на файловете на базата данни
Тъй като нарастването на файла на базата данни е доста ресурсоемка операция, може да изглежда, че задаване на този растеж в процентни съотношения може да бъде добра идея. Съгласен съм, че много насоки препоръчват задаване на фиксирано увеличение в MB, а не в проценти. Те обаче не обясняват причините. Въз основа на практиката не се препоръчва да задавате увеличение на файл с база данни над 1 GB, тъй като MS SQL Server ще задели 1 GB 2 пъти, вместо 2 GB наведнъж.
Също така, ако разпределите по-малко от 32 MB , рано или късно базата данни просто ще се забави. Така че е по-добре да зададете фиксирано увеличение на файловете на базата данни от 32 до 1024 MB. Защо обаче е невъзможно да се посочи увеличението на файловете на базата данни като процент? Оказва се, че щом файлът е по-малък от 1 MB, СУБД закръгля тази стойност до 0 MB и спира да увеличава този файл. В резултат на това системата не работи. За да разберете колко трябва да увеличим файла, просто извършвайте ежедневен анализ, за да проверите колко печели всеки файл в MB и задайте подходящото число в диапазона от 32 до 1024 MB. Можем да събираме статистически данни за нарастването на файловете на базата данни по следния начин. - Има много външни ключове за таблица
Опитвали ли сте някога да проверите плана, когато изтривате поне един ред от таблица, която се позовава от почти стотици други таблици? Ще се изненадате да разберете колко много вложени цикли има. Всички те са проверки на външни ключове. Ето защо, ако таблиците са големи (над един милион записа), по-добре е да деактивирате външните ключове за таблица, в която данните ще бъдат изтрити. След това ще трябва да изтриете всички необходими и свързани данни. След това активирайте външните ключове. Подобна ситуация възниква при каскадни актуализации и изтривания. Ако има много външни връзки (стотици), тогава изтриването дори на един ред може да доведе до дълго и много обширно блокиране. - Много ненужни индекси
Много често можете да видите в насоките, че при създаване на външни ключове е необходимо да се изградят индекси, особено когато се използват тези ключове за обединения. Трябва да проверите дали се използват индекси, в противен случай тези ненужни индекси само ще забавят всякакви операции за промяна на данни. За да проверите това, използвайте следната заявка: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
- Неефективно използване на ресурсите
Често се препоръчва да съхранявате дневника на транзакциите и файла на базата данни на различни устройства за съхранение. Ако използвате RAID 10 с 4 и повече SSD диска, тогава няма смисъл да изолирате файловете един от друг. За по-висока скорост, ако е необходимо, базата данни tempdb може да се съхранява на диск, който е разделен от RAM. Освен това твърде големи количества RAM, предоставени на СУБД, ще накарат последната да запълни цялата памет с неподходящи планове за заявки. - Лоши архиви
Винаги е необходимо не само да се проверяват създадените резервни копия, но и да се преместват на тестов стенд и да се възстановяват. Всичко това трябва да бъде автоматизирано с допълнително уведомяване на администраторите както за проблемно, така и за успешно възстановяване. - Лоша устойчивост на отказ
Преди да създадете клъстер от два или повече сървъра, трябва да се уверите, че системата за съхранение на данни също е устойчива на отказ. Ако последният не успее, целият толеранс на отказ ще бъде намален до нула. - Сложно Диагностика без прости проверки
Ако има прекъсване на системата, първо трябва да проверите регистрационните файлове на MS SQL Server и след това да копаете по-дълбоко. Първо трябва да извършите прости проверки и след това да преминете към сложна диагностика. - Изгубени маси
Таблиците могат да бъдат разширени с ненужни данни, които трябва да бъдат архивирани в отделна база данни или изтрити. Освен това таблиците може повече да не се използват.
Това са ситуациите, на които съм попадал. Затова бих искал да препоръчам да не повтаряте горните грешки.
Искате ли да споделите своя опит или подобни грешки при администрирането на бази данни, не се колебайте да ме уведомите – ще се радвам да ги обсъдим.
