(Возврат на основную страницу)

Содержание номера за Январь 2010 год

SQL Server
для администраторов

Январь 2010
№ 1 (43)

Чарльз Кинкейд

Резервные копии только для копирования (COPY_ONLY)

Кендал Ван Дайк

Подсчитываем количество строк в таблице быстро и безболезненно

Оскар Д. Гарсия

Преобразование IP-адреса в данные о географическом местоположении

А. Гладченко

Основы репликации SQL Server 2008. Часть 2 

Резервные копии только для копирования (COPY_ONLY)

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

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

Резервное копирование и восстановление связаны в SQL Server в так называемую «модель восстановления». В этой статье я не рассматриваю все стороны концепции моделей восстановления, но вы всегда можете получить дополнительную информацию по этой теме в электронной документации.

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

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

Если же с момента перевода базы данных на модель полного восстановления полное резервное копирование ни разу не выполнялось, внутренняя цепочка выстраиваться не будет. Доля журналов транзакций в объеме дискового пространства, занимаемом базой данных, будет довольно скромной; бурно разрастаться они также не будут. Но как только будет произведено полное резервное копирование, зародится цепочка резервных копий журналов. Журнал не может усечь себя сам — для этого нужно произвести его резервное копирование. Иначе он просто будет продолжать расти до тех пор, пока на займет все свободное место на диске (В SQL Server Express — пока не будет достигнут максимально допустимый размер файла журнала, даже если к этому моменту на диске еще будет оставаться место).

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

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

Казалось бы, достаточно просто добавить COPY_ONLY в SQL­выражение, сгенерированное SSMS. Но не все так просто. Диалоговое окно восстановления в SSMS 2005 не может работать с резервными копиями только для копирования. Следовательно, если вы делаете резервную копию вручную, восстанавливать вам ее также придется вручную.

Подсчитываем количество строк в таблице быстро и безболезненно

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

Первое, что обычно можно услышать от большинства советчиков в такой ситуации: «Используйте select count(*) from [table]». Но есть тут два неприятных момента. Во­первых, для того чтобы узнать ответ, потребуется просмотреть таблицу полностью; испробуйте­ка count(*) на таблице в миллион строк — получите пару сотен тысяч чтений (и пару минут ожидания результата). Во­вторых, метод count(*) не слишком хорош, когда вам требуется узнать, сколько строк в каждой из таблиц вашей базы данных.

Но, к счастью, есть в SQL Server системная функция, способная решить обе эти проблемы: sp_spaceused (см. описание процедуры в документации). Если вызвать ее без параметров, она вернет данные об использовании дискового пространства всей базой данных, в контексте которой функция была запущена; если же ей передать в качестве параметра имя какого­нибудь объекта (имя таблицы, например), она вернет количество строк, а также размер используемого и зарезервированного таблицей и ее индексами дискового пространства. При более пристальном взгляде на sp_spaceused выясняется, что информацию о количестве строк функция получает из таблицы sysindexes в SQL 2000 или из DMV sys.dm_db_partition_stats в SQL 2005/2008. А раз данные предоставляются системным объектом, необходимость просмотра таблицы отпадает — вот и решена первая проблема!

Со второй проблемой можно разобраться, итеративно применив sp_spaceused к таблицам с помощью курсора (или с помощью недокументированной хранимой процедуры sp_foreachtable) и сохранив полученные результаты во временной таблице... Можно, впрочем, обратиться к системным объектам непосредственно.

Преобразование IP-адреса в данные о географическом местоположении

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

О чем эта статья?

В этой статье вы не найдете информацию о том, как узнать и сохранить IP­адрес посетителя. Это процедура осуществляется на прикладном уровне средствами внешнего интерфейса на базе ASP.Net, PHP и т. п. Предметом рассмотрения данной статьи является использование IP­адреса для получения данных географического характера. Эти данные состоят из следующих блоков: страна, регион, город, почтовый код (индекс), код города (там, где он используется). В некоторых странах почтовые коды или индексы не применяются.

Основы репликации SQL Server 2008. Часть 2*

(Возврат на основную страницу)