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

Содержание номера за Декабрь 2009 год

SQL Server

Декабрь 2009
№ 12 (108)

Editorial

Родни Лэндрам

Будь это действительно чрезвычайная ситуация...

Programming

Аруп Чакраборти

Двадцать советов для написания хорошей хранимой процедуры

Ицик Бен-Ган

Наборы группировки. Часть 26

Other

Томас Грохсер, Линдсей Аллен Вариант стратегии быстрого
и надежного резервного копирования/восстановления VLDB по сети. Часть 1

Эндрю Сиссон

Помощник по миграции на SQL Server. Часть 2

Будь это действительно чрезвычайная ситуация...

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

Большинство людей уверены в том, что уж их­то беда обойдет стороной; так когда­то думал и я. Пережив, однако, настоящую чрезвычайную ситуацию - это около трех недель без газа, электричества, льда, денег, воды, мобильной связи и пива - я несколько пересмотрел свои взгляды на вероятность прихода стихийного бедствия. Я имею в виду ураган Иван, ударивший в 2004 году по моему городу - Пенсаколе, штат Флорида. Компания, в которой я работал, не располагала в то время сервером на резервной площадке на отдаленной территории, не затронутой ураганным ветром скоростью 120 миль в час.

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

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

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

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

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

Двадцать советов для написания хорошей хранимой процедуры

Программирование хранимых процедур - это очень распространенная задача в мире современных баз данных. Такие процедуры пишут не только разработчики баз данных, но также разработчики приложений. Администраторам БД (DBA) также необходимо программировать хранимые процедуры. В самом деле, при приеме на работу меня очень часто спрашивали: «Сколько хранимых процедур вы написали?».

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

Наборы группировки. Часть 2*

DOWNLOAD

*-См. Ицик Бен­Ган. Наборы группировки. Часть 1 // SQL Server для профессионалов. 2009. № 11.

В прошлом месяце в статье «Наборы группировки. Часть 1» я рассказал о наборах группировки и познакомил вас с новым, появившимся в SQL Server 2008 вложенным предложением GROUP BY - GROUPING SETS. В этом месяце я опишу три новых особенности SQL Server 2008, относящихся к наборам группировки: параметры CUBE и ROLLUP, а также функцию GROUPING_ID.

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

Вариант стратегии быстрого и надежного резервного копирования/восстановления VLDB по сети. Часть 1

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

Введение

Резервное копирование и восстановление баз данных в SQL Server похожи на многие другие, окружающие нас в реальном мире вещи; Вы сможете не понять их ценность, когда столкнетесь с ними впервые. За эти годы все мы сталкивались с такими ситуациями, когда не оказывалось под рукой нужной резервной копии; следствием этого становилась потеря бизнеса компанией, потеря работы для людей и потери данных. Компании находят оправдания, для того, чтобы не делать резервное копирование и не создавать план восстановления. Часто слышно фразы, подобные этим: «У нас есть кластер, так что нам не нужна резервная копия», или «Нам не нужен план восстановления, потому что мы делаем резервные копии каждый день». Что мы поняли за эти годы, так это то, что резервные копии и план восстановления нужны во всех случаях.

Помощник по миграции на SQL Server. Часть 2*

Настройка SSMA

У SSMA есть несколько опций конфигурации. В нижеприведенных разделах вкратце говорится о наиболее важных настройках.

Связанные серверы (linked servers). Первоначальное подключение к экземпляру Oracle для извлечения схемы не требует наличия связанного сервера; если вы решаете предоставить управление переносом данных SSMA, вы должны создать связанный сервер. Связанный сервер также используется для сравнения результатов с Oracle и SQL Server, когда тестирование завершено. Связанный сервер можно настроить в диалоговом окне SSMA Connect to Oracle, которое показано на рис. 1.

Параметры ведения журнала (logging opti­ons). Вы можете заставить SSMA вести журнал преобразования и заданий миграции в формате со значениями, разделенными запятыми (CSV), или в HTML. Вы можете также указать размер файлов журнала и каталог для сохранения журнала. Настройте параметры ведения журнала так, чтобы они наилучшим образом соответствовали требованиям аудита вашего проекта.

Параметры преобразования кода (code conversion options). Большинство миграций будет включать перенос схемы, связанной с конкретным пользователем или приложением, хотя SSMA может также конвертировать объекты системной схемы, что полезно, если существуют элементы кода, обращающиеся к системным объектам. Вы можете, кроме того, указать, чтобы SQL Server эмулировал пакеты Oracle. Помимо настройки эмуляции, можно также указать конвертирование последовательностей в столбцы Identity, исключения и столбцы ROWID.

Дополнительные параметры (Additional options). Также доступны дополнительные настраиваемые пользователем опции, такие как параметры, используемые для формирования аналитических отчетов SSMA, тестовых данных для тестирования перенесенных объектов схемы, настройки сценария на языке определения данных (DDL) для создания объектов и параметры синхронизации рабочей области SSMA с версиями схемы в исходной либо целевой базе данных. О многих из этих опций я расскажу более подробно позже.

Пакеты, последовательности и обработка исключений Oracle (Oracle packages, sequences, and exception handling). SQL Server и Oracle используют различные методы работы с некоторыми задачами баз данных. К примеру, Oracle имеет более надежный  функционал обработки исключений, который сложно воспроизвести в SQL Server. Данные различия зачастую являются очагом проблем при миграции. Для облегчения этих сложностей SSMA включает симуляцию пакетов, последовательностей и обработки исключений Oracle, все это хранится в базе данных SYSDB. SQL Server предлагает многие собственные решения, сравнимые с пакетами, последовательностями и методами обработки исключений Oracle в виде системных функций, идентификаторов, определяемых системой и пользователем сообщений об ошибках и функций T-SQL. SSMA позволяет вам либо продолжить применять методики Oracle, либо использовать вместо этого методики SQL Server. SSMA можно, кроме того, настроить таким образом, чтобы симулировать пакеты Oracle, обработку исключений и выполнять преобразования из последовательностей в идентификаторы.

Аналитические отчеты (Assessment Reports). В аналитическом отчете SSMA рассчитывается сложность кода PL/SQL Oracle на основе нескольких факторов, в частности, числа строк кода, типов фигурирующих инструкций, использования пакетов, последовательностей, обработки исключений, операций агрегирования, наличия и сложности вложенных инструкций Select и курсоров. На основании этих факторов и других соображений SSMA оценивает количество человеко­часов, необходимое для переноса объектов схемы с Oracle на SQL Server. Вы можете настроить аналитический отчет таким образом, чтобы в нем указывался процент объектов, которые SSMA может конвертировать, и процент тех объектов, которые программа конвертировать не в состоянии. Для кода, который не может быть преобразован автоматически, дается оценка количества человеко­часов, необходимых для того, чтобы сделать это вручную. Аналитический отчет можно создать до того, как было запущено любое задание, для этого ему нужно подключение к исходной базе данных Oracle. На рис. 2 показан типичный аналитический отчет SSMA.

Преобразование схемы (Schema conversion). Чтобы упростить перенос кода, воспользуйтесь предоставляемой SSMA возможностью преобразования схемы, которая позволяет конвернировать код Oracle PL/SQL в код T-SQL. Первый шаг при конвертировании кода - создание сценариев DDL для таблиц и всех вспомогательных структур, таких как индексы, ограничения и триггеры. Вы можете преобразовать отдельные таблицы или все таблицы сразу. Сценарии генерируются в рабочей области SSMA, чтобы их можно было проверить, отредактировать и сохранить для будущего использования, но объектов на сервере­получателе они, в действительности, не создают. Если вы удовлетворены преобразованными DDL, сценарии можно загрузить на целевой сервер, воспользовавшись вкладкой Load to Database, расположенной в главном меню страницы SSMA для Oracle, или щелкнув правой кнопкой мыши по отдельному объекту и выбрав Load to Database, как показано на рис. 3. SSMA выполняет соотнесение и преобразование типов, проводя некоторую оценку для учета несовместимостей, как, например, наличие типов без масштаба (scale). В этом случае SSMA преобразует данные Oracle в такой же тип данных в SQL Server с максимально допустимым масштабом. К примеру, VARCHAR2(10) Oracle будет преобразован в VARCHAR(10), но VAR­CHAR2 Oracle будет сконвертирован в VARCHAR(MAX) (как показано на рис. 4). SSMA также предоставляет возможность подбора совместимого типа. Вы можете выбрать целевой тип данных для заданного исходного типа данных, воспользовавшись выпадающим меню Target type, показанным на рис. 5. Соотнесение типов может выполняться на уровне объектов или на уровне базы данных.

Преобразование функций, процедур и триггеров (Con­ver­si­on of functions, pro­ce­dures, and triggers). Код объектов, отличный от DDL­определений таблиц, также легко создать в SSMA. Из исходной схемы Oracle можно выбрать объекты, которые следует преобразовать в объекты целевой машины SQL Server. Сценарии всех объектов сначала записываются и сохраняются в рабочем пространстве SSMA для проверки либо внесения дополнительных измерений, а затем загружаются в базу данных SQL Server. SSMA также позволяет преобразовывать код объектов в динамический SQL. Код PL/SQL Oracle, содержащий вызовы и исключения, автоматически конвертируется в динамический SQL.

Режимы преобразований (Mo­des of conversions). SSMA поддерживает пять настроек конфигурации, в частности: Project In­for­mation (Проектная информация), Ge­ne­ral (Conversion and Mig­ra­ti­on) (Основной (Преобразование и миг­ра­ция)), Loading Objects (Загруз­ка объек­тов), GUI и Type Map­ping (Сопоставление типов). Для этих пяти параметров конфигурации существуют четыре дополнительных настройки для большего контроля конечным пользователем: De­fault (По умолчанию), Op­ti­mis­tic (Оптимис­тический), Full (Полный) и Cus­tom (Поль­зовательский) (как показано на рис. 6). SSMA рекомендует использовать режим Default большинству пользователей. Режим Op­ti­mis­tic создан, чтобы сохранить больше синтаксических структур Orac­le, и полученный код, как правило, легче читать, однако этот режим может быть не столь точен, как режим Full. В режиме Full происходит наиболее полное преобразование; но получающийся в результате код сложнее читать, чем код, сконвертированный в режиме Opti­mis­tic. Режим Custom дает пользователю полный контроль над тем, как происходят преобразования из кода и типов Oracle в код и типы SQL Ser­ver.

Перенос данных

Хотя для выполнения переноса данных с Oracle на SQL Server приложение SSMA 2.0 использует связанный сервер, при использовании SSMA 3.0 связанный сервер не требуется. В обеих версиях SSMA вы можете перенести данные, щелкая правой кнопкой мыши по объектам схемы и выбирая пункт Migrate Data. Если выбрано несколько таблиц, SSMA будет переносить данные из них последовательно. Триггеры и ограничения внешних ключей в целевой базе данных отключаются перед переносом данных и включаются по завершении. Результаты завершенного переноса данных представлены в отчете о миграции данных (Data Migration Report), который показан на рис. 7. Перенос данных с Oracle на SQL Ser­ver - это операция массовой загрузки, при которой перенос строк данных из таблиц Oracle в таблицы SQL Server осуществляется в транзакциях. Настройки проекта позволяют указать число строк, загружаемых в SQL Server за каждую транзакцию. Обратите внимание, что SSMA 2.0 не переносит таблицы, имеющие столбцы с большими объектами (LOB). Вместо этого вам придется мигрировать таблицы, содержащие LOB­столбцы, вручную, используя функции OPENQUERY или OPEN­ROWSET, либо пакетными средствами типа BCP и BUL­KINSERT.

Тестирование

Один из наиболее важных и зачастую упускаемых шагов при переносе проектов - это тестирование, но мастер тестирования (Testing Wizard), предоставляемый SSMA, упрощает этот процесс. Мастер тестирования используется, чтобы убедиться в том, что преобразованные и перенесенные объекты, такие как процедуры, функции и представления, работают в SQL Server должным образом. Во время тестирования процедур и функций одни и те же входные параметры (данные) могут быть поданы как в исходные, так и в преобразованные процедуры и функции с тем, чтобы можно было сравнить выходные параметры или результирующие наборы. Тестирование миграции (миграционное тестирование) состоит из нескольких шагов, включая подготовку и выполнение тестовых примеров (test cases).

Тестовые примеры. При создании нового тестового примера вы должны выбрать один или более объектов для тестирования, которые уже перенесены на получающий экземпляр SQL Server. Один из важных шагов в тестировании с помощью SSMA состоит в том, чтобы определить, использовать ли существующие данные в таблицах, к которым обращается код, или заставить SSMA сформировать новые тестовые данные для упоминаемых объектов. Если вы решите использовать тестовые данные, сгенерированные SSMA, они будут помещены в дополнительные таблицы. Затем мастер тестирования выполняет резервное копирование реальных данных в упоминаемых таблицах и использует сгенерированные данные из дополнительных таблиц. Лучше всего (хотя это и не обязательно) осуществлять перед тестированием резервное копирование реальных данных, поскольку хранимые программы обычно производят над основными таблицами какие либо преобразования языка манипулирования данными (DML). SSMA предоставляет настройку для осуществления резервного копирования основных (реальных) данных перед выполнением каких­либо тестовых примеров. Если вы хотите иметь больше контроля, вы можете определить количество строк и диапазоны значений с учетом типов данных столбцов базовой таблицы и их способности принимать значения NULL и формировать исходя из этого тестовые данные.

Выполнение тестового примера. После того как указано, использовать реальные или сгенерированные данные, и выполнено резервное копирование, пользователя просят ввести входные параметры. Настройки входных параметров учитывают общее число различных значений, диапазоны или типы величин, возможность наличия значений NULL. Перед итоговым выполнением SSMA показывает данные, используемые для источника Oracle и сопоставленного целевого экземпляра SQL Server. Когда вы запускаете тестовый пример (который показан на рис. 8), SSMA заменяет подлинные данные в основных таблицах тестовыми данными из дополнительных таблиц и выполняет внутренне сформированные в базе данных Test_Platform_DB хранимые процедуры. Этот процесс завершается передачей определенных пользователем входных параметров как хранимым программам T-SQL, так и оригинальным хранимым программам PL/SQL. Когда тестовый пример завершен и на исходной, и на целевой базах данных, результаты сравниваются. Этот процесс повторяется столько раз, сколько необходимо. По завершении всего тестового примера формируется тестовый отчет; в нем показаны переданные во время каждого прогона тестовые параметры, а также сказано, был ли тест успешным. Миграционное тестирование средствами SSMA экономит время в плане формирования тестовых данных, выполнения объектов и сравнения результатов. Когда тестирование завершено, в базовые таблицы можно вернуть реальные данные.

Преобразование приложений и динамического SQL

Как и в случае с любым окружением базы данных, не весь код для доступа к данным представлен в базе данных как хранимые процедуры. Логика зачастую внедрена в клиентские приложения, динамический SQL и другие вызываемые модули. Эта проблема может оказать значительный эффект на любое задание миграции вследствие сложностей, связанных с переписыванием, тестированием и развертыванием совершенно нового кода для поддержки базы данных. SSMA берется решить эту проблему с помощью конвертера периода исполнения. Конвертер периода исполнения на лету преобразует внедренный и динамический код PL/SQL в код T­SQL путем применения обертки. Хотя конвертирование кода во время исполнения в долгосрочной перспективе, возможно, не является оптимальным решением, оно, несомненно, представляет приемлемый вариант до тех пор, пока код смогут переписать так, чтобы использовать преимущества возможностей SQL Server.

Трансляция

SSMA содержит в своем составе платформу для тестирования T­SQL, в которой можно вводить код PL/SQL и преобразовывать его в T-SQL. Как правило, Test SQL используется для трансляции или преобразования индивидуальных команд.

Миграция на SQL Server

SSMA - отличный инструмент для автоматизации преобразования данных и кода при переходе с Oracle на SQL Server.

Дополнительная возможность переноса данных делает SSMA пригодным вариантом для выполнения миграции с Oracle на SQL Server.

За дополнительной информацией о переходе на SQL Ser­ver обращайтесь на веб­сайт Migrate to SQL Ser­ver по адресу http://www.microsoft.com/sql/solutions/mig­ration/default.mspx.

*-См. Эндрю Сиссон. Помощник по миграции на SQL Server. Часть 1 // SQL Server для профессионалов. 2009. № 11.

Дополнительно

SQL Server Metadata Toolkit

http://sqlmetadata.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=36601#DownloadId=94975

MSDN's SQL 2005 tool kit updated to 2008 for managing metadata in SQL Server Integration Services, Analysis Services and Reporting Services using built-in features including data lineage, business and technical metadata and impact analysis.
This project is an update on the project released on MSDN Code Gallery SQL Server Metadata Toolkit (SQL Server Metadata Toolkit)
The Database has been updated to handle longer names for attributes, and some views have been updated to handle SQL 2005 and SQL 2008 GUIDs.
There are enhancements to add Column names as Attributes, and with the Lookup, Fuzzy Lookup, Derived Column and Multiple Hash components, additional information is added to the Column name attributes.
The DependancyViewer has not been changed (other than updates to make it VS2008 compliant).
Alpha 2 has added handling for Containers, which was missing from the MSDN version. These are now recursively checked for Data Flows.

Venatek SQL Server File Archive - Watched Folder Saves Files to Database

http://venatekfilearchive.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=36411#DownloadId=94472

Project Description

One or more watched folders are defined. Each folder is given a category. A Windows service watches the folders. When a file is dropped into a folder, the system inserts it into a SQL Server table. Admin is done via a Windows forms app written using Developer Express controls. C#

Overview

Administration - Windows Forms Application

The Windows Forms application is the general administrative tool for this system. Use it to create and manage categories and watched folders. Also use this tool to search and view the application log, which is written to a SQL Server table. Note that all logged information is also written to the system event log. This Windows Forms application is also used to search for and to retrieve files which have been saved to the archive.

Note that because Archived File is a child entity of Watched Folder, the archived file are available in a tab below the watched folder detail.

Windows Service

The Windows service does the work of watching the folder and processing files. Each file that is dropped into a watched folder will be picked up by the service, inserted into the database and then removed from the file system. Each archived file record will be associated with both the folder where it was originally dropped and also the category that was assigned to that folder at the time that the file was processed.

SQL Server Extended Properties Quick Editor

http://xqued.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=36369#DownloadId=94346

This tool is a SQL Server extended properties editor. Especifically designed to edit tables and column descriptions, and management extended properties quickly.

Current stable release version 1.3.2 Review the documentation. Win32 installer supplied, it will remove old versions prior to install the current version.

Review source code can help you use if you are interested in sql server SMO.

SqlMonitoring Tool

http://sqlmonitoring.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=36373#DownloadId=94356

Project Description

The SqlMonitoring tool makes it possible to monitor SQL 2000, 2005, 2008 environments and send alerts to a central database (SQL 2008). A client can be used to view the alerts en perform actions on them. This tool is a good alternative if you do not have the budget or infrastructure for tools like SCOM.

New release will be available for testing this year. http://sqlmonitoring.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=34811

Sql Monitoring FAQ

This tool was designed to be an open source alternative for tools like SCOM 2007 and BMC Patrol. The tool also focusses primarly on SQL Server.

The feature complete version will be released on August 30th but this version is complete for as far as the service is concerned. Most work has to be done on the client, but the basics are available.

For a quickstart download the binaries and follow the steps in the included Quick Start Guide. To run the tool you will need at least SQL Server 2008. Any version will work, although for large environments it's recommended to use the Standard or Enterprise edition.

SQLscripta

http://www.sqlsoft.co.uk/binaries/SQLscripta.zip

SQLscripta makes finding and scripting stored procedures, functions, views, and triggers simple. Easy to use, it allows simple or more complex searching across multiple databases, and scripts can then be copied using a right-click "Copy", Ctrl+C, drag-drop, or viewed in the application and copied from there.

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