SQL Server: Лучшие советы по эффективному обслуживанию баз данных

По нескольку раз в неделю у меня проcят совета, как отлично обслуживать рабочую базу данных. Иногда вопросы исходят от админов баз данных, которые используют новые решения и отыскивают помощи в подгонке практики обслуживания под свойства новых баз данных. Почаще вопросы исходят от людей, которые не являются проф админами баз данных, но, по той либо другой причине, обладают базой данных либо несут за нее ответственность. Я предпочитаю именовать их «невольными админами баз данных». Задачка этой стать состоит в предоставлении учебника по лучшим вариантам обслуживания баз данных для .

Как и в случае с большинством задач и процедур в мире информационных технологий, годящегося на хоть какой случай действенного решения обслуживания баз данных не существует, но есть несколько главных областей, которые практически всегда требуют внимания. Моя личная 1-ая пятерка этих областей, перечисленная без определенного порядка значимости:

Управление файлами данных и журналов
Фрагментация индекса
Статистика
Обнаружение повреждений
Запасные копии

У необслуживаемой (либо плохо обслуживаемой) базы данных могут появиться препядствия в одной либо нескольких из этих областей, что с течением времени может привести к нехороший работе приложений либо даже простоям и потере данных.

В этой статье я объясню, почему эти трудности важны, и покажу некие обыкновенные пути их смягчения. Мои разъяснения будут основаны на SQL Server® 2005, но я также выделю главные отличия, с которыми можно столкнуться в SQL Server 2000 и дальнейшем SQL Server 2008.

Управление файлами данных и журналов

1-ая область, которую я всегда рекомендую проверить при принятии управления базой данных – это характеристики, связанные с управлением файлами данных и журнальчика (транзакций). Поточнее говоре, следует убедиться, что:

Файлы данных и журнальчика разделены друг от друга, также изолированы от всего остального
Автоматическое повышение настроено правильно
Настроена автоматическая инициализация файлов
Автоматическое сжатие отключено, и сжатие не является частью какого-нибудь плана обслуживания

Когда файлы данных и журнальчика (которые, в эталоне, вообщем должны быть на различных томах) находятся в одном томе с хоть каким другим приложением, которое делает либо расширяет файлы, появляется возможность для фрагментации файлов. В файлах данных лишная фрагментация файлов может давать маленький вклад в нехорошую работу запросов (в особенности тех, что просматривают очень огромные объем данных). В файлах журналов она может нанести еще более суровый удар по производительности, в особенности если автоматическое расширение установлено только на очень маленькое повышение размера файла всякий раз, как в нем появляется потребность.

Файлы журнальчика внутренне разбиты на разделы, называемые виртуальными файлами журнальчика (Virtual Log Files – VLF), и чем выше фрагментация в файле журнальчика (я использую тут единственное число, так как наличие нескольких файлов журнальчика не имеет огромного смысла – в базе данных следует держать только один), тем больше число VLF. После того, как число VLF в файле журнальчика превосходит, скажем, 200, может усугубиться производительность связанных с журнальчиком операций, таких как чтение журнальчика (скажем, для транзакционной репликации/отката), запасное копирование журнальчика и даже триггеров в SQL Server 2000 (реализация триггеров поменялось в SQL Server 2005 с журнальчика транзакций на инфраструктуру версий строк).

Что касается размеров файлов данных и журнальчика, идеальнее всего создавать их с подходящим начальным размером. Для файлов данных при выборе начального размера должна приниматься во внимание возможность прибавления к базе дополнительных данных в наиблежайшей перспективе. К примеру, если начальный размер данных равен 50 ГБ, но понятно, что в течение последующих 6 месяцев будет добавлено еще 50 ГБ данных, имеет смысл сходу сделать файл данных размером в 100 ГБ заместо того, чтоб растить его до этого размера в течение нескольких месяцев.

С файлами журналов дело, как досадно бы это не звучало, обстоит несколько труднее – нужно учесть такие причины, как размер транзакции (длительные транзакции не могут быть удалены из журнальчика до собственного окончания) и частоту запасного копирования журнальчика (так как конкретно при нем удаляются неактивные части журнальчика). Дополнительные сведения приведены в «8 Steps to Better Transaction Log Throughput («8 шагов к улучшению пропускной возможности журнальчика транзакций»)», пользующейся популярностью записи в блоге на SQLskills.com, написанной моей супругой, Кимберли Трипп (Kimberly Tripp).

После того, как размеры файлов установлены, за ними следует следить в разные моменты, и их следует заблаговременно наращивать вручную в подходящее время суток. Автоматическое повышение следует бросить в качестве предосторожности на всякий случай, чтоб файлы могли расти при необходимости в случае какого-нибудь необыкновенного действия. Причина, по которой управление файлами не следует полностью оставлять автоматическому повышению, заключается в том, что автоматическое повышение маленькими кусочками ведет к фрагментации файлов и что автоматическое повышение может занимать много времени, тормозя работу приложения в внезапные моменты.

Размер автоматического роста следует установить на определенное значение, а не на процент, чтоб ограничивать время и место, нужные для выполнения автоматического роста, если оно происходит. К примеру, в случае 100-гигабайтного файла данных лучше зафиксировать размер автоматического роста как 5 ГБ, а не, скажем, 10%. Это означает, что он всегда будет возрастать на 5 ГБ вне зависимости от текущего размера файла, а не на объем, увеличивающийся после каждого роста файла (10 ГБ, 11 ГБ, 12 ГБ и т.д.).

Когда журнальчик транзакций возрастает (или вручную, или через автоматическое повышение), он всегда инициализируется нулями. Файлы данных имеют то же поведение по дефлоту в SQL Server 2000, но начиная с SQL Server 2005 в их можно включить секундную инициализацию файла, которая пропускает инициализацию файлов нулями и, как следствие, делает повышение и автоматическое повышение фактически моментальными. В противоположность всераспространенным представлениям, эта функция доступна во всех выпусках SQL Server. Дополнительные сведения можно отыскать, введя «instant file initialization» («мгновенная инициализация файла») в указателе электрической документации для SQL Server 2005 либо SQL Server 2008.

В конце концов, следует позаботиться, чтоб никаким образом не было включено сжатие. Сжатие можно использовать для уменьшения размера файла данных либо журнальчика, но это очень твердый, ресурсозатратный процесс, который вызывает широкую логическую фрагментацию просмотра в файлах данных (подробности см. ниже) и ведет к низкой производительности. Я изменил запись о сжатии в электрической документации SQL Server 2005, включив предупреждение об этом. Вобщем, сжатие отдельных файлов данных и журнальчика вручную может быть допустимо при особенных обстоятельствах.

Автоматическое сжатие в особенности вредоносно, так как оно запускается каждые 30 минут в фоновом режиме и пробует сжимать базы данных, для которых выставлен параметр автоматического сжатия. Этот процесс не полностью предсказуем в том, что он сжимает только базы данных с более чем 25% свободного места. Автоматическое сжатие употребляет массу ресурсов и вызывает понижающую производительность фрагментацию, так что оно не нужно при всех обстоятельствах. Его всегда следует отключать при помощи:

ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;

План постоянного облуживания, включающий выдачу базе данных команды на сжатие вручную, практически настолько же плох. Если обнаружится, что база данных повсевременно вырастает после того, как план обслуживания сжимает ее, то это вызвано тем, что базе данных данное место необходимо для работы.

Идеальнее всего позволить базе данных вырасти до размера размеренного состояния и избегать сжатия вообщем. Дополнительные сведения о недочетах использования сжатия, также кое-какие комменты по новым методам в SQL Server 2005 можно отыскать в моем древнем блоге MSDN® на blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx.

Фрагментация индексов

Кроме фрагментации на уровне файловой системы и снутри файла журнальчика, также вероятна фрагментация снутри файлов данных, в структурах, хранящих данные таблиц и индексов. Снутри файла данных может произойти два базисных типа фрагментации:

Фрагментация снутри отдельных страничек данных и индекса (иногда называемая внутренней фрагментацией)
Фрагментация снутри структур индекса либо таблиц, состоящих из страничек (называемая логической фрагментацией просмотра и фрагментацией просмотра по экстентам)

Внутренняя фрагментация – это наличие в страничке огромных пустых пространств. Как указывает рис. 1, любая страничка в базе данных имеет размер 8 КБ и 96-байтный заголовок; как следствие, страничка может хранить приблизительно 8096 байтов данных индексов либо таблиц (определенные внутренние структуры таблиц и индексов для данных и структур строк можно отыскать в моем блоге по адресу sqlskills.com/blogs/paul, в категории Inside The Storage Engine («Внутри механизма хранения»)). Пустое место может появиться, если любая таблица либо запись в индексе превосходят по размерам половину странички, так как тогда на страничке можно сохранить только одну запись. Поправить это очень трудно либо нереально, так как для исправления нужно изменение схемы таблицы либо индекса, к примеру, методом конфигурации ключа индекса на что-то, что не вызывает случайные точки вставки, как это делает GUID.

SQL Server: Наилучшие советы по действенному обслуживанию баз данных

Рис. 1. Структура странички базы данных

Почаще внутренняя фрагментация вызывается переменами данных, такими как вставки, обновления и удаления, что может бросить на страничке пустые места. Неправильное распоряжение коэффициентом наполнения также может содействовать фрагментации, подробности приведены в технической документации. Зависимо от схемы таблицы/индекса и черт приложения это пустое место возможно окажется неприменимым для повторного использования после его возникновения, что может привести к неизменному росту неиспользуемого места в базе данных.

Разглядим, для примера, таблицу из 100 миллионов строк, где средняя запись имеет размер 400 байтов. С течением времени шаблон конфигурации данных приложения приведет к возникновению в среднем 2800 байтов свободного места на страничку. Общее место, требуемое таблицей, составляет 59 ГБ, это выводится методом последующего расчета: 8096-2800 / 400 = 13 записей на 8-килобайтную страничку, потом делим 100 миллионов на 13, чтоб получить число страничек. Если б место не пропадало, то на одной страничке можно было бы уместить 20 записей, что уменьшает общее требуемое место до 38 ГБ. Большущая экономия!

Неиспользуемое место на страничках данных/индекса может, таким макаром, привести к хранению такого же объема данных на большем числе страничек. Это не только лишь приводит к большему расходу места на диске, да и означает, что запросу нужно провести больше операций ввода/вывода, чтоб прочитать тот же объем данных. И все эти дополнительные странички занимают больше места в кэше данных, занимая тем память сервера.

Логическая фрагментация просмотра вызывается операцией, называемой разбиением странички. Это происходит, когда запись нужно воткнуть на определенную страничку индекса (согласно определению ключа индекса), но на страничке недостаточно места, чтоб расположить вставляемые данные. Страничка разбивается напополам, и приблизительно 50% записей передвигаются на свежевыделенную страничку. Эта новенькая страничка обычно не является на физическом уровне смежной со старенькой и, как следует, называется фрагментированной. Концепция фрагментации просмотра по блокам подобна. Фрагментация снутри структур таблиц/индексов оказывает влияние на возможность SQL Server делать действенные просмотры как по всей таблице/индексу, таки и ограниченные предложением WHERE запроса (такие как SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000).

На рис. 2 показаны свежесозданные странички индекса со 100-процентным коэффициентом наполнения – странички полны, и физический порядок страничек совпадает с логическим порядком. На Рис. 3 показана фрагментация, которая может происходить после случайных вставок/обновлений/удалений.

SQL Server: Наилучшие советы по действенному обслуживанию баз данных

Рис. 2. Свежесозданные странички индекса без фрагментации, странички полны на 100%

SQL Server: Наилучшие советы по действенному обслуживанию баз данных

Рис. 3 Странички индекса, показывающие внутреннюю фрагментацию и фрагментацию логического просмотра после случайных вставок, обновлений и удалений

Фрагментацию иногда можно предупредить, изменив схему таблицы/индекса, но, как я упомянул выше, это может быть очень сложным либо неосуществимым. Если предотвращение нереально, есть методы устранения фрагментации после ее появления – а именно, методом восстановления либо реорганизации индекса.

Восстановление индекса предполагает создание новейшей копии индекса (аккуратненько сжатой и так непрерывной, как это может быть, с следующим отказом от старенькой и фрагментированной). Так как SQL Server делает новейшую копию индекса перед удалением старенькой, ему требуется свободное место в файлах данных, примерно равное размеру индекса. В SQL Server 2000, восстановление индекса всегда проводилось в автономном режиме. Но в SQL Server 2005 Enterprise Edition восстановление индекса можно выполнить в интерактивном режиме с некими ограничениями. Реорганизация, с другой стороны, употребляет имеющийся метод для сжатия и дефрагментации индекса; она просит только 8 КБ дополнительного места для выполнения – и всегда работает в интерактивном режиме. Кстати, в SQL Server 2000 я специально написал код реорганизации как интерактивную, экономящую место кандидатуру перестройке индекса.

В SQL Server 2005 следует направить внимание на команды ALTER INDEX … REBUILD для восстановления индексов и ALTER INDEX … REORGANIZE для их реорганизации. Этот синтаксис подменяет команды SQL Server 2000 DBCC DBREINDEX и DBCC INDEXDEFRAG, соответственно.

Меж этими способами есть много различий, влияющих на выбор 1-го из их, таких как создаваемый объем журнальчика транзакций, требуемый объем свободного места в базе данных и возможность оборвать процесс без утраты выполненной работы. Технический документ, к котором дискуссируются эти различия, и прочее можно отыскать на microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx. Этот документ основан на SQL Server 2000, но концепции отлично переносятся на поздние версии.

Некие юзеры просто решают восстанавливать либо перестраивать все индексы каждую ночь либо каждую неделю (используя, к примеру, вариант с планом обслуживания) заместо того, чтоб выяснять, какие индексы фрагментированы и какое достоинства даст устранение фрагментации. Хотя это может быть неплохим решением для невольного админа базы данных, который просто вожделеет применить какое-то решение с наименьшими усилиями, это возможно окажется очень нехорошим выбором для более больших баз данных и систем, где ресурсы в недостатке.

Более непростой подход предполагает внедрение динамического административного представления sys.dm_db_index_physical_stats (либо DBCC SHOWCONTIG в SQL Server 2000) для повторяющегося определения фрагментированных индексов и выбора того, следует ли работать на их, и если да, то как. В данном техническом документе также дискуссируется внедрение этих более узеньких выборов. Вприбавок, некие эталоны кода для выполнения этой фильтрации можно отыскать в примере D записи электрической документации, посвященной динамическому административному представлению sys.dm_db_index_physical_stats в SQL Server 2005 (msdn.microsoft.com/library/ms188917) либо примере E записи электрической документации, посвященной DBCC SHOWCONTIG в SQL Server 2000 и дальше (на msdn.microsoft.com/library/aa258803).

Какой бы способ ни употреблялся, безотступно рекомендуется часто находить и устранять фрагментацию.

Обработчик запросов является частью SQL Server, которая решает, как надо исполнять запрос – а конкретно, какие таблицы и индексы использовать и какие операции делать на их для получения результатов; это называется планом запросов. В число более принципиальных входных данных этого процесса принятия решений заходит статистика, описывающая рассредотачивание значений данных для столбцов снутри таблицы либо индекса. Разумеется, чтоб быть полезной для обработчика запросов, статистика должна быть четкой и свежайшей, по другому могут быть выбраны непродуктивные планы запросов.

Статистика создается методом считывания данных таблицы/индекса и определения рассредотачивания данных для соответственных столбцов. Статистика может быть построена методом проверки всех значений данных для определенного столбца (полной проверки), но ее также можно выстроить на базе обозначенного юзером процента данных (проверки примеров). Если рассредотачивание значений в столбце является относительно равномерным, то проверки примеров может быть довольно, и это делает создание и обновление статистики более резвым, чем при полной проверке.

Направьте внимание, что статистику можно автоматом создавать и поддерживать, включив характеристики базы данных AUTO_CREATE_STATISTICS и AUTO_UPDATE_STATISTICS, как показано на рис. 4. Они включены по дефлоту, но тем, кто только-только унаследовал базу данных, стоит проверить их, чтоб убедиться. Иногда статистика может устареть – в этом случае может быть ее обновление вручную при помощи операции UPDATE STATISTICS для определенного набора статистических характеристик. В качестве кандидатуры можно использовать хранимую функцию sp_updatestats, которая обновляет всю старую статистику (в SQL Server 2000 sp_updatestats обновляет всю статистику вне зависимости от возраста).

SQL Server: Наилучшие советы по действенному обслуживанию баз данных

Рис. 4. Изменение характеристик базы данных через SQL Server Management Studio

Если необходимо обновлять статистику как часть плана постоянного обслуживания, то необходимо держать в голове об одной хитрости. И UPDATE STATISTICS, и sp_updatestats по дефлоту употребляют ранее обозначенный уровень сбора данных (если указан некий) – и он может быть ниже, чем полная проверка. Восстановления индекса автоматом обновляют статистику при помощи полной проверки. В случае обновления статистики вручную после восстановления индекса можно получить еще наименее точную статистику! Это может произойти, если проверка примеров из обновления вручную перепишет полную проверку, сделанную восстановлением индекса. С другой стороны, при реорганизации индекса статистика вообщем не обновляется.

Опять-таки, многие имеют план обслуживания, обновляющий всю статистику в какой-нибудь момент до либо после восстановления всех индексов – и сами того не зная, они возможно окажутся с наименее четкой статистикой. Если выбрано обычное восстановление всех индексов время от времени, то оно позаботится и о статистике. Если избран более непростой путь с устранением фрагментации, это стоит делать и для обслуживания статистики. Я предлагаю последующее:

Проанализируйте индексы и обусловьте, на каком индексе следует работать и как провести дефрагментацию.
Обновите статистику для всех индексов, которые были восстановлены.
Обновите статистику для всех неиндексированных столбцов.

Дополнительную информацию о статистике можно отыскать в техническом документе «Statistics Used by the Query Optimizer in Microsoft® SQL Server 2005″ («Статистика, применяемая оптимизатором запросов в Microsoft SQL Server 2005») (microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx).

Обнаружение повреждений

Я поведал об обслуживании, связанном с производительностью. Сейчас пора переключиться на рассказ об обнаружении повреждений и смягчении последствий.

Очень маловероятно, чтоб в базе данных содержалась совсем никчемная информация, которая никого не тревожит – потому что же можно убедиться, что данные остаются неповрежденными и восстанавливаемыми в случае аварийной ситуации? Подробности сведения воедино полной стратегии аварийного восстановления и высочайшей доступности выходят за пределы темы этой статьи, но для начала можно сделать несколько обычных вещей.

Подавляющее большая часть повреждений вызываются «оборудованием». Почему оно в кавычках? Ну, оборудование тут – это по сути условное обозначение для «что-то в подсистеме ввода-вывода, под SQL Server». Подсистема ввода/вывода состоит из таких частей, как операционная система, драйверы файловой системы, драйверы устройств, контроллеры RAID, кабели, сеть и сами диски. Масса мест, где могут появиться (и появляются) проблемы.

Одной из более всераспространенных заморочек является сбой питания в момент, когда диск ведет запись на страничку базы данных. Если диск не сумеет окончить запись, до того как у него кончится электричество (либо если операции записи кэшируются и запасного источника питания не хватит для чистки кэша диска), результатом может стать незавершенный образ странички на диске. Это может произойти, так как 8-килобайтная страничка базы данных на самом деле состоит из 16 смежных 512-байтных секторов диска. Неполная запись могла записать некие из секторов из новейшей странички, но бросить некие из секторов из вида предшествующей странички. Такая ситуация именуется разорванной страничкой. Как можно найти, когда это случается?

У SQL Server есть механизм для обнаружения таковой ситуации. В него входят сохранение нескольких битов из каждого сектора странички и запись определенного шаблона на их месте (это происходит конкретно перед записью странички на диск). Если при считывании странички шаблон поменялся, то SQL Server знает, что страничка «порвана», и выдает ошибку.

В SQL Server 2005 и поболее поздних версиях доступен более полный и способный найти любые повреждения на страничке механизм, называемый контрольными суммами страничек. В него входят запись контрольной суммы всей странички на страничку прямо перед ее записью и потом ее проверка при считывании только-только записанной инфы, точно так же, как при обнаружении порванных страничек. После включения контрольных сумм страничек страничку нужно прочесть из буферного пула, поменять любым образом и записать на диск опять, чтоб она стала защищена контрольной суммой странички.

Так что идеальнее всего включить контрольные суммы страничек начиная с SQL Server 2005 и дальше, а для SQL Server 2000 включить обнаружение разорванных страничек. Чтоб включить контрольные суммы страничек, используйте последующий оператор:

ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;

Чтоб включить обнаружение разорванных страничек для SQL Server 2000, используйте последующий оператор:

ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;

Эти механизмы позволяют найти наличие повреждений на страничке, но только при чтении странички. Как можно просто организовать чтение всех распределенных страничек? Наилучшим способом для выполнения этого (и обнаружения повреждений хоть какого другого рода) является внедрение команды DBCC CHECKDB. Вне зависимости от обозначенных вариантов эта команда всегда будет читать все странички в базе данных, таким макаром заставляя инспектировать все контрольные суммы страничек либо обнаружение порванных страничек. Следует также установить предупреждения, чтоб можно было выяснить, когда юзеры сталкиваются с повреждениями при выполнении запросов. Юзер также может быть уведомлен о всех вышеперечисленных дилеммах, используя предупреждение о ошибках уровня серьезности 24 (рис. 5).

SQL Server: Наилучшие советы по действенному обслуживанию баз данных

Рис. 5. Установка предупреждения для всех ошибок серьезности 24

Так что другой неплохой рекомендацией является постоянное выполнение DBCC CHECKDB на базах данных для проверки их целостности. Существует много вариантов этой команды и вопросов о том, как нередко ее следует делать. Как досадно бы это не звучало, технического документа, в каком это бы дискуссировалось, на данный момент не существует. Но, так как DBCC CHECKDB была основной частью кода, которой я написал SQL Server 2005, я много писал о ней в блогах. См. категорию моего блога «CHECKDB From Every Angle» («CHECKDB со всех сторон»)(sqlskills.com/blogs/paul), в какой имеется много подробных статей, посвященных проверке целостности, советам и практическим советам. Для невольных админов баз данных неплохим правилом является выполнение DBCC CHECKDB после каждого полного запасного копирования базы данных. Я рекомендую делать последующую команду:

DBCC CHECKDB (‘MyDatabase’) WITH NO_INFOMSGS,
ALL_ERRORMSGS;

Если эта команда что-то выдает, DBCC отыскал повреждения в базе данных. Тогда вопрос преобразуется в: «Что делать, если DBCC CHECKDB находит повреждения?». Здесь-то на сцене и возникают запасные копии.

При появлении повреждения либо другого сбоя более действенным методов восстановления является восстановление базы данных из запасных копий. Естественно, это подразумевает наличие таких копий и то, что сами они не повреждены. Очень нередко юзеры желают знать, как вынудить серьезно покоробленную базу данных работать вновь, когда у их нет запасной копии. Обычный ответ заключается в том, что это нереально, во всяком случае без утраты данных, способной изуродовать всю бизнес-логику и реляционную целостность данных.

Так что постоянное запасное копирование очень рекомендуется. Тонкости использования запасного копирования и восстановления выходят далековато за границы этой статьи, но позвольте мне дать короткую аннотацию по созданию стратегии запасного копирования.

Во-1-х, следует часто делать полное запасное копирование базы данных. Это дает единое состояние на момент времени, до которого потом можно восстанавливать. Полную запасную копию базы данных можно сделать, используя команду BACKUP DATABASE. Примеры имеются в электрической документации. Для дополнительной защиты можно использовать параметр WITH CHECKSUM, который инспектирует контрольные суммы (если они есть) читаемых страничек и вычисляет контрольную сумму для всей запасной копии. Следует избрать частоту, отражающую утрату данных либо работ, которую можно для себя позволить. К примеру, запасное копирование всей базы данных раз в денек значит, что в случае сбоя может быть потеряна дневная работа в данных. В случае использования только полного запасного копирования базы данных следует быть в модели восстановления SIMPLE (обычно называемой режимом восстановления), чтоб избежать сложностей, связанных с управлением ростом журнальчика транзакций.

Во-2-х, держите запасные копии по нескольку дней на случай, если одна из их будет повреждена – древняя запасная копия лучше, чем никакой. Также следует инспектировать целостность собственных запасных копий, используя команду RESTORE WITH VERIFYONLY (снова же, см. электрическую документацию). Если при разработке запасной копии был применен параметр WITH CHECKSUM, при использовании команды проверки будет испытано, верна ли еще контрольная сумма запасной копии, также контрольные суммы страничек снутри нее.

В-3-х, если каждодневное полное копирование базы данных может привести к недопустимому для компании уровню утрат данных/изготовленной работы, может быть, стоит заглянуть в разностные запасные копии базы данных. Разностная запасная копия базы данных базирована на полной запасной копии базы данных и содержит запись всех конфигураций с момента сотворения последней полной копии (нередко считается, что разностные запасные копии являются дополнительными – это не так). В качестве примера стратегии можно привести каждодневное снятие полной запасной копии с созданием разностной копии каждые четыре часа. Разностная копия предоставляет вариант восстановления к состоянию на дополнительный момент времени. В случае использования только полного и разностного запасного копирования баз данных также следует использовать модель восстановления SIMPLE.

В конце концов, лучшие способности по восстановлению предоставляет запасное копирование журналов. Оно доступно только в моделях восстановления FULL (и BULK_LOGGED) и предоставляет запасные копии всех записей журнальчика, сделанных с момента последнего запасного копирования журнальчика. Поддержание набора запасных записей журнальчика, также периодическое проведение полного (и, может быть, разностного) запасное копирования позволяет вернуть состояние на хоть какой момент времени с точностью до минутки. Платить за это приходится тем, что журнальчик транзакций вырастает, пока его не «освобождают», создав запасную копию. В качестве примера стратегии тут можно привести каждодневное снятие полной запасной копии с созданием разностной копии каждые четыре часа и запасной копии журнальчика каждые полчаса.

Выбор стратегии запасного копирования и организация ее внедрения могут быть непростыми. Как минимум, следует часто делать полное запасное копирование базы данных, чтоб убедиться в наличии как минимум 1-го момента времени, состояние базы данных на который может быть восстановлено.

Как можно узреть, обеспечение работоспособности и доступности базы данных просит выполнения нескольких неотклонимых задач. Вот мой последний контрольный перечень для невольных админов баз данных, которым досталось управление базами:

Удалите избыточною фрагментации файла журнальчика транзакций.
Правильно установите автоматическое повышение.
Отключите любые запланированные операции сжатия.
Включите секундную инициализацию файлов.
Сделайте постоянный процесс обнаружения и удаления фрагментации индекса.
Включите AUTO_CREATE_STATISTICS и AUTO_UPDATE_STATISTICS и сделайте постоянный процесс для обновления статистики.
Включите контрольные суммы страничек (либо, как минимум, обнаружение порванных страничек на SQL Server 2000).
Удостоверьтесь в наличии постоянного процесса для выполнения DBCC CHECKDB.
Удостоверьтесь в наличии постоянного процесса для выполнения полного запасного копирования базы данных, также разностного запасного копирования и копирования журнальчика для восстановления состояния на момент времени.

Я привел в статье команды T-SQL, но почти все можно сделать и из Management Studio. Надеюсь, что я отдал вам кое-какие полезные указания по действенному обслуживанию баз данных. Если у вас есть комменты либо вопросы, отправьте их мне —paul@sqlskills.com.

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.