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

Вы — администратор баз данных. Просьба приостановить работу системы для восстановления магнитной ленты, потому что вы допустили оплошность, неминуемо приведет к безвозвратной утрате доверия пользователей, не говоря уже о руководстве. Что же делать? Подготовьте инструкции по работе с базой данных и следуйте им независимо от того, каких бы высот мастерства вы ни достигли. Ниже перечислены 9 правил, которые следует неукоснительно соблюдать при работе с базами данных.

1. Сделайте резервную копию

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

2. Используйте транзакции

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

Для запуска транзакции можно задействовать такой программный код:

BEGIN TRANSACTION GoodDBA
UPDATE Account
SET Balance = 0
WHERE BalanceDate >= DATEADD(day, -1, GETDATE())

Теперь вы можете увидеть результаты своих изменений, выполнив, например, следующий программный код:

SELECT *
FROM Account
WHERE BalanceDate >= DATEADD(day, -1, GETDATE())

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

COMMIT TRANSACTION GoodDBA

Если вам не нравятся результаты, отмените изменения, откатив транзакцию с помощью программного кода:

ROLLBACK TRANSACTION GoodDBA

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

3. Откажитесь от выделения

Не запускайте потенциально опасные сценарии, поочередно выделяя по одному фрагменту, особенно если нельзя запускать фрагменты более одного раза. Вы рискуете выделить не тот фрагмент, запустить один и тот же фрагмент повторно или случайно выполнить весь сценарий разом из-за неосторожного движения мышью. Лучше выделить комментариями фрагменты исходного текста, которые не требуется выполнять. Я предпочитаю поместить начальные символы комментария /* непосредственно после выполняемого программного кода, а завершающие символы комментария */ — в конце документа. Таким образом удается перемещаться вниз по документу, выполняя по одной инструкции.

4. Изучите особенности своего соединения

Прежде чем выполнить деструктивную команду, всегда следует убедиться, что операция выполняется на соответствующем сервере и базе данных. Если ваша серверная среда похожа на мою, то в ней насчитываются десятки серверов разработки, интеграции и контроля качества (QA). Крайне нежелательно усекать рабочую таблицу, если в действительности вы намеревались работать на сервере QA. Кроме того, при работе с пакетами DTS или мастером импорта/экспорта Microsoft SQL Server всегда проверяет правильность выбора исходного и целевого серверов. Подавляющему большинству администраторов баз данных случалось хотя бы раз перепутать исходный и целевой серверы.

5. Избегайте изоляции

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

6. Аккуратно обращайтесь с таблицами

Изучая новую таблицу, полезно увидеть тестовые данные, чтобы понять, как используется таблица. Запустить sp_help недостаточно. При этом нагрузка как на сервер, так и на клиентский компьютер может оказаться довольно высокой, если запустить SELECT * из таблицы производственного размера, а затем щелкнуть Stop в SQL Query Analyzer после того, как по каналу связи будет передано достаточно тестовых данных. В следующий раз попробуйте запустить

SELECT TOP 100 * FROM mytable

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

7. Не злоупотребляйте конструктором таблиц

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

8. Изменяйте, а не уничтожайте

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

9. Семь раз отмерь, один отрежь

Закрывая процесс SQL Server, используйте DBCC INPUTBUFFER и DBCC OUTPUTBUFFER, чтобы не уничтожить по ошибке какой-нибудь другой процесс. Команда

DBCC INPUTBUFFER()

возвращает текущую команду, выполняемую по указанному идентификатору процесса сервера (SPID). Команда

DBCC OUTPUTBUFFER()

возвращает содержимое выходного буфера памяти в шестнадцатеричном и ASCII форматах. Результат выглядит аналогично команде DEBUG операционной системы DOS и он позволяет понять, что видит пользователь данного SPID.

Таким образом, составив список оптимальных приемов, вы сможете безошибочно выполнять операции с базами данных.