(Возврат на основную страницу)
Некоторые рекламные объявления заставляют нас думать, что если произошло несчастье, поможет только большой страховой полис. Но несмотря на их заверения для возмещения ущерба на самом деле требуется коечто еще. А в некоторых случаях просто невозможно вернуть бизнес на прежний уровень.
Майк Хоутек, ректор Solid Quality Learning и мой коллега, является одним из лучших в мире специалистов по средствам копирования и обеспечения высокой надежности SQL Server. В качестве консультанта он работает с самыми разными компаниями — от фирм, входящих в Fortune 100, до организаций всего с десятком служащих. Двенадцать клиентов Хоутека располагались в здании Всемирного торгового центра в НьюЙорке. 11 сентября 2001 года семь из них были уничтожены. Хотя какието данные могли уцелеть, людей, которые позаботились бы о них, не осталось.
Выжившие сотрудники оставшихся пяти компаний обратились к Хоутеку за помощью. Из первой позвонили через два дня после атаки. Хоутек всего полдня проработал с ней, потому что все принадлежащие компании данные и вся информация, необходимая для их воссоздания, погибли при крушении зданийблизнецов. Бизнес не выжил. Две другие компании оказались в аналогичной ситуации — у них просто ничего не осталось, чтобы начать работать снова. Две оставшиеся компании смогли восстановиться — в первую очередь потому, что они реализовали рекомендации Хоутека по предотвращению бедствий и обеспечению способности встретить их подготовленными. Он описал свой опыт работы с этими уцелевшими компаниями.
Первую неделю после атаки Хоутек спал не более четырех часов в день. Несмотря на все предпринятые его клиентами планирование и подготовку на случай аварии, восстановление потребовало несколько недель тяжелого труда. Однако обе компании в течение недели смогли хотя бы начать работу благодаря счастливому совпадению. До нападения они заказали новую вычислительную технику, так что через неделю после 11 сентября они связались с производителями оборудования и перенаправили ее в новые места расположения компаний. Эти сделанные заранее заказы на оборудование стали стартовой точкой для их новых систем. Одна компания полностью функционировала уже через 18 дней, другая начала нормально работать через месяц.
Масштаб события сделал полное восстановление подразделения отличным от других аварий, требующих заново построить систему, по двум причинам. Вопервых, изза колоссальных размеров разрушения никто не знал, насколько быстрым будет восстановление. Ни руководство компании, ни акционеры не дышали в затылок Хоутеку, спрашивая: «Долго ли еще?» То, что ктото из сотрудников выжил, само по себе было чудом. Мысль о том, что бизнес сможет опять функционировать, выходила за пределы какихлибо ожиданий. Поэтому никакое давление извне не заставляло компании торопиться с восстановлением.
Вторая причина была скорее личной. Хотя многие стратегии предотвращения бедствий предписывают убедиться в том, что более чем у одного сотрудника есть все системные пароли и они знают, где хранятся все резервные копии, редко кто планирует действия на тот случай, когда вся команда IT станет недоступной. Обе выжившие компании потеряли большую часть сотрудников IT, а оставшиеся люди были в шоке. К счастью, у Хоутека имелась основная необходимая информация, поскольку он ранее помогал компаниям формировать планы восстановления на случай катастрофы. Для обеих компаний он был единственным лицом, знавшим требования технологии бизнеса, и именно поэтому ему пришлось на время расстаться со сном. Хотя руководители компании и акционеры не ожидали мгновенного восстановления, Хоутек понимал, что он должен помочь им сделать это как можно раньше. Он предпринял следующие шесть основных шагов, чтобы бизнес обеих компаний вновь заработал:
1. выяснил, какими умениями обладали выжившие сотрудники;
2. раздобыл финансирование для работ по восстановлению;
3. нашел новое место и заказал новое оборудование для наиболее жизненно важных систем;
4. нанял по контракту служащих для построения систем заново;
5. нашел все резервные копии и документацию процессов и выяснил, какие данные были попрежнему доступны;
6. организовал работу сотрудников подразделения IT и нанятых по контракту специалистов.
Для обеих компаний частью работ по восстановлению было планирование всей новой инфраструктуры информационного управления, встраиваемой в стратегии предотвращения бедствий и восстановления, включая запасные системы горячего и теплого резервирования. Хоутек пояснил, что он стал экспертом по созданию репликаций именно изза тех работ, которые он выполнял для обеспечения готовности к нештатным ситуациям. Делая это, он сразу же получает выигрыш в виде распределенной наращиваемой системы, и у него имеется «теплый» резерв, к которому можно обратиться при потере.
Спустя два года после трагедии обе компании функционируют с вновь набранным штатом сотрудников, правда, сегодня они не столь велики, как до 11 сентября. Хоутек в течение первых нескольких месяцев сотрудничал с ними, выполняя тестовые проверки и составляя отчеты. Он попрежнему обладал уникальными знаниями об этих системах, поскольку сам спроектировал и внедрил их. Однако он верил, что его роль постепенно сойдет на нет приблизительно за год, потому что планировал за это время передать свои знания сотрудникам подразделений IT. Теперь у обеих компаний есть избыточное оборудование вне основного местоположения, которое можно быстро включить в работу. У них имеются кластеры, удаленные на 25 миль от их основного местоположения, и они реализовали передачу журналов для поддержания удаленных кластеров в синхронном состоянии с основными системами. Теперь интервал потери данных ограничен 5 минутами. По иронии судьбы обе компании заложили этот уровень избыточности в свои планы два года назад и собирались приступить к их реализации с октября 2001.
Я поинтересовалась у Хоутека, извлек ли он какието уроки из собственного опыта работы после 11 сентября. Он сказал, что самый важный урок заключается в том, что его рекомендации клиентам, которые он делал многие годы, оказались верны: ни один сценарий не будет лишним при обеспечении готовности к бедствиям. Факторы, позволившие выжившим компаниям восстановить бизнес, — это планирование, подготовка и настойчивость.
Мы продолжаем обзор методов работы с массивами в SQL Server. В этой части статьи также представлены сводные данные об их производительности.
В этой статье рассказывается, как с помощью команды Windows NT COMP можно быстрее и с меньшими усилиями, чем на TSQL, сравнивать содержимое таблиц.
Старая добрая DOS не уходит надолго. Она заложена в гены Windows, и неважно, назовете ли вы ее «командной подсказкой» или «подсказкой MSDOS». Несмотря на всю GUIзацию приложений в последнее десятилетие, команды NT остаются полезной составляющей инструментария программирования. К примеру, большинство из вас пользуется расширенной процедурой xp_cmdshell для выполнения самых популярных команд NT, таких как DIR, COPY, DEL и REN. xp_cmdshell позволяет АБД манипулировать файлами вне SQL Server из хранимых процедур TSQL. Но доступно еще много команд NT. Некоторые из них могут оказаться чрезвычайно эффективными для определенных задач в SQL Server. В этой статье я расскажу о применении команды COMP. Обратите внимание, что она используется только в Windows NT, а не в Windows 95/98.
Сравнение таблиц на TSQL
Мне кажется забавным, что задача сравнения данных в двух таблицах оказалась такой сложной для языка SQL. В нем имеется несколько типов сравнения, и всем требуются разные уровни усилий по программированию. Простейший из них сравнивает первичные ключи (или любые другие уникальные ключи) в двух таблицах. Затем идет сравнение неуникальных ключей (потому что надо учитывать наличие дубликатов). Наконец, еще более трудным является сравнение содержимого целых строк.
Выяснить, имеет ли регистрационное имя доступ к вашим базам данных, порой не легче, чем найти иголку в стоге сена. В этой статье Алан Митчелл показывает, как обуздать мощь SQLDMO, чтобы справиться с этой задачей.
В большинстве компаний члены команды IT приходят и уходят, особенно в случае работы по контракту. Когда они увольняются, задача человека, отвечающего за серверы SQL, состоит в том, чтобы «вычистить» их полномочия доступа к базам данных. Если в компании придерживаются расслабленной политики добавления пользователей, то это может быть весьма трудоемкой задачей. На моем последнем месте работы мне пришлось управляться с 50 серверами. Ясно, что перспектива проверки каждого из них выглядела по меньшей мере непривлекательно. Добавьте к этому еще и тот факт, что на большинстве этих серверов конечные пользователей (некоторые из них уже не являлись служащими компании) имели право создавать объекты. Все это означало, что мне требовалось просмотреть каждый тип объектов и выяснить, кто чем владел (я просто не мог запустить сценарий удаления, если они были собственниками). Мне было нужно быстрое решение, так что я обратился к SQLDMO. В этой статье я познакомлю с результатами своих трудов.
Как выбрать кластеризованный индекс? Всегда ли его надо создавать для первичного ключа? В этой статье автор делится премудростями и подскажет коекакие ответы.
Везде — от клиентских сайтов до сетевых телеконференций — неизбежно просят дать совет относительно выбора кластеризованного индекса. В частности, люди хотят знать, всегда ли кластеризованный индекс должен совпадать с первичным ключом. Если вы ветеран администрирования баз данных, то, вероятно, тоже отвечаете на такие вопросы, не задумываясь. И, как и у меня, ответом будет: «Ну, все зависит от обстоятельств». Однако недавно я натолкнулся на одну возможную причину, по которой следует проявить осторожность при отделении кластеризованного индекса от первичного ключа. Она связана с неразрешимыми блокировками (deadlock). Условия немного сложны, но я объясню, как отделение кластеризованного индекса от первичного ключа может повлечь за собой возникновение тупиковых ситуаций, и продемонстрирую потенциальное средство исцеления.
Написать сценарий, который работает с множеством распределенных по нескольким серверам баз данных, не так просто, как может показаться. Автор развивает идею переключения контекста, чтобы облегчить автоматизацию этой трудоемкой задачи.
Одной из основных характеристик любой базы данных является ее размер. Весьма вероятно, что у вас, как у администратора баз данных, не раз спрашивали: «Какого же размера сейчас твоя (наша, моя) база данных?» Ответ не требует больших усилий; это можно выяснить у Enterprise Manager или запустить sp_spaceused, быстро записать ответ и распечатать или отправить по электронной почте результат. Если у вас всего несколько баз данных, ручной подход работает прекрасно, а что, если у вас 40 или 50 баз данных, распределенных по дюжине производственных серверов, и надо еженедельно составлять по ним отчет? Или же вы только что развернули какието аналитические витрины данных и хотите проанализировать, насколько быстро растут кубы, — тогда для вашего спокойствия, возможно, потребуются даже ежедневные отчеты.
(Возврат на основную страницу)