(Возврат на основную страницу)
Статистическая выборка для
верификации резервных копий баз данных
Томас Ларок (Thomas LaRock)
Инструкция Showplan: операторы
недели — BookMark Lookup и Key Lookup
Фабиано Аморим (Fabiano Amorim)
Обработка ошибок SQL Server
Билл Грациано (Bill Graziano)
Мониторинг группы связанных
серверов
Калдип Риндани (Kuldip Rindani)
Статистическая выборка
для верификации резервных копий баз данных
Томас Ларок (Thomas LaRock)
Огромная рабочая нагрузка администратора баз данных способна превратиться в угрозу для принятой практики резервного копирования и восстановления данных, но находчивость и умелый подход к выработке хорошей тактики обычно могут обеспечить выход из трудного положения. В случае Тома, открывшееся ему решение явилось следствием поедания крабов. Чтобы минимизировать риск сбоя при восстановлении базы данных, поврежденной в результате аварии, можно прибегнуть к статистической выборке.
Я часто слышу об администраторах баз данных, главная забота которых — наличие хорошей стратегии резервного копирования; однако, большинство более опытных администраторов БД сознают необходимость иметь хорошую стратегию восстановления, включающую в себя получение резервных копий только как составную часть. За всеми этими разговорами о стратегии восстановления я не могу не видеть, что никто не думает о важности формирования процедуры, которая, как ни странно, позволяет удостовериться в том, что вы способны восстановить свои данные.
Хорошая стратегия восстановления включала бы:
Последовательное планирование создания резервных копий.
Тестовое восстановление баз данных.
Выполнение команды DBCC CHECKDB для поиска повреждений.
Итак, почему же лишь немногие администраторы баз данных формируют стратегию восстановления, которая включает регулярное тестирование созданных резервных копий с целью удостовериться в том, что эти копии пригодны для восстановления? Я думаю, есть две главных причины.
Во-первых, большинство просто не сознает необходимость иметь такую проработанную процедуру. Однако, они практически наверняка займутся ее встраиванием в общий процесс сразу же после того, как впервые на практике столкнутся с аварийным сбоем при попытке выполнить запрошенное восстановление.
Во-вторых, существует реальная проблема массы. С каждыми неделей, месяцем и годом большинство профессионалов в области баз данных обрастают все новыми и новыми обязанностями. В своем вычислительном центре я уже сейчас обслуживаю свыше 3 000 баз данных. Мысль о том, что я мог бы ежедневно заниматься восстановлением каждой из них и выполнять команду DBCC CHECKDB, смехотворна.
Так как же быть, если надо верифицировать множество резервных копий, а времени не хватает на то, чтобы их создать?
Инструкция Showplan:
операторы недели — BookMark Lookup и Key Lookup
Фабиано Аморим (Fabiano Amorim)
Фабиано продолжает свою миссию,
которая состоит в том, чтобы рассказать о важнейших
операторах инструкции Showplan, используемых оптимизатором запросов
SQL Server. На этой неделе он встречается со «звездой» — оператором Key
Lookup.
Это одаренный исполнитель, известный, однако, главным образом своей ролью в
трудно выполнимых запросах, где индекс не «покрывает» данные, необходимые
для выполнения запроса. Если вы знаете, почему и при
каких обстоятельствах замедляется поиск ключа, эти
знания очень пригодятся при оптимизации
производительности запросов.
Пора поговорить о «кинозвезде» из числа операторов: Key Lookup так знаменит, что
я не мог написать об этом операторе, не воздав ему
должные почести.
Устраивайтесь поудобнее, наберите себе попкорна и расслабьтесь. Понимаю, вы
знакомы с этим великолепным оператором, но надеюсь,
прочитав данную статью, откроете для себя что-то новое
в его функциональном поведении и получите несколько хороших советов. К
тому моменту, как вы закончите чтение, я надеюсь обеспечить вам более
полное понимание операторов Bookmark Lookup и Key
Lookup.
Как будто в поисках анонимности, этот оператор трижды менял свою «личность» в последних трех версиях SQL Server. В версии SQL 2000 он назывался BookMark Lookup. Появилась версия SQL 2005, его переименовали, и он явился просто как операция «Clustered Index Seek». С момента появления версии SQL Server 2005 SP2 этот оператор носит имя Key Lookup, что для меня имеет больший смысл. В тексте плана выполнения он представляется как «Clustered Index Seek».
Прежде всего, я дам небольшое пояснение относительно способа использования индекса ядром SQL Server, а также объясню, почему операции с неупорядоченными закладками стоят так дорого. Кроме того, я создам процедуру, которая обеспечивает возврат некоторой информации, позволяющей понять, когда операции поиска (lookup) хороши, а когда оказывается, что лучше сканировать (scan), чем искать (lookup).
Обработка ошибок SQL Server
Билл Грациано (Bill Graziano)
В этой статье рассматриваются основные принципы обработки ошибок с помощью конструкции TRY CATCH языка T-SQL, появившейся в версии SQL Server 2005. Эта обработка включает применение стандартных функций с целью возврата информации об ошибке и использование блока TRY CATCH в хранимых процедурах и транзакциях.
Мониторинг группы
связанных серверов SQL Server с сервера SQL Server
Калдип Риндани (Kuldip Rindani)
В этой статье рассматривается некая базовая структура мониторинга, и, следовательно, у вас, вполне вероятно, может быть другое представление о том, как это делается.
Введение
Основная цель этой статьи — разобраться в том, как с сервера SQL Server вести мониторинг группы связанных серверов SQL Server.
Прежде, чем я начну, мне необходимо дать некоторые пояснения:
В этой статье используются методика связывания серверов (Linked Server Technique) и программирование сокетов (Socket Programming) — темы, которые я рассматривать не буду, поскольку они раскрываются в других статьях.
Хотя предварительное знакомство с данной тематикой, безусловно, будет полезно, оно не является обязательным.
Применимость
Рассматриваемый проект можно использовать для любого случая организации элементарного мониторинга базы данных. Однако, он разрабатывался специально для мониторинга в интересах обслуживания производства (production support monitoring), когда в таблицах базы данных отслеживаются определенные данные. Примером, который я могу предложить, является банковская сфера, где конкретные транзакции должны передаваться в удаленную систему по заранее установленному графику. После того, как такие транзакции переданы, их состояние в базе данных обновляется, и они получают статус переданных в удаленную систему.
(Возврат на основную страницу)