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

Содержание номера за Май 2007 год

Зачем беспокоиться о резервном копировании

Это первая статья из серии, посвященной изучению основных аспектов резервного копирования сервера SQL Server. Серия начинается с самых основ — с объяснения того, почему резервное копирование баз данных является важным делом. Ответ на вопрос, зачем создаются резервные копии баз данных, может наполнить смыслом многие другие решения.

Резервное копирование данных сервера SQL Server — одно из таких дел, которые мы делаем потому, что считаем, что нам необходимо их делать. Резервное копирование так же полезно для вас, как правильное питание и физические упражнения. К сожалению, в деле создания резервных копий сервера SQL Server люди зачастую достигают той же степени успеха, что и в случае с диетой и физзарядкой.

Создавайте резервные копии, чтобы вас не уволили

Первая важная причина создания резервных копий базы данных — если этого не делать, вас могут уволить (или пострадает ваша карьера). В Интернете можно найти множество историй людей, уволенных из­за того, что они не создали резервную копию базы данных. Google­поиск фразы «fired because of no database backup» («уволен из­за отсутствия резервной копии базы данных») возвращает около 145 000 ссылок, часть которых приводит к подробным историям.

Симон Гэлбрайт (Simon Galbraith) из фирмы Red Gate Software рассказывает следующее: «Свою первую настоящую работу я получил в 1992 году и, оглядываясь назад, могу отметить, что самым замечательным в ней было высокое качество ИТ­обеспечения. У нас была полнофункциональная электронная почта на базе Windows, действующие телеконференции, надлежащим образом организованные сетевые диски и все то, что сейчас, в 2005 году, мы считаем обязательным. К тому же, все это по большей части вполне успешно и надлежащим образом работало. Такой уровень ИТ на пять­десять лет опережал свое время.

В фирме работало 300 человек, в основном физики со степенью доктора философии (PhD), и все ИТ­нужды коллектива обслуживали два человека. Майк, непритязательный скромник, отвечавший за ИТ, считался богом.

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

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

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

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

Наш босс, обычно невозмутимый Стив, лишился дара речи. Буквально. Он не мог говорить в течение двух часов, а когда смог, попросил Алана уйти. В конечном итоге было решено: Алану дадут время на то, чтобы заново проделать всю работу. Алан восстановил работу в заданный срок и продолжил разрабатывать то, что практически все признали бы за более удачную версию этого программного обеспечения. То есть затрачены были не одна бессонная ночь и большой объем неоплаченного сверхурочного времени».

Часть историй об увольнениях, вызванных отказом от резервного копирования баз данных, принад­лежит бывшим сотрудникам, которые, очевидно, расстроены случившимся и, осмелюсь сказать, не совсем объективны. Интересно, что по крайней мере один человек рассказывает об увольнении, которое явилось следствием того, что другой сотрудник не обеспечил резервное копирование базы данных. Разработчик копировал базу данных с одного сервера на другой, и в результате серии событий, которая заставляет Мэрфи из Закона Мэрфи выглядеть оптимистом, поврежденными в конце концов оказались как исходная, так и целевая базы данных. Это не привело бы к такой ужасной проблеме при наличии соответствующих резервных копий, но таковых не оказалось. Вместо того чтобы уволить сотрудника, ответственного за резервное копирование, фирма уволила программиста, в должностные обязанности которого не входило создание резервных копий базы данных.

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

Создавайте резервные копии ради существования фирмы

Помимо того, что это служит причиной увольнения, достаточно серьезный промах в резервном копировании может стоить вашей фирме самого ее существования. Можете вы себе представить, что ваша фирма, функционирующая в онлайновом режиме, остается абсолютно недоступной в течение целого дня? В июле 2003 года это произошло с фирмой Orbitz. К счастью, в конце концов, эта фирма сумела вернуть все свои данные обратно в онлайновый режим. Трудно подсчитать стоимость такого простоя, но, я думаю, можно уверенно сказать, что потери достаточно велики и любая фирма, которая уже находится на краю своего существования, не сможет выжить в данной ситуации. Можно только воображать, насколько разрушительнее были бы последствия, не окажись на месте резервных копий.

Согласно отчету Национального управления архивов и документации (National Archives and Records Administration), 93 процента фирм, которые лишились своих центров данных более чем на десять дней, регистрируются как обанкротившиеся в течение одного года.

Создавайте резервные копии, потому что таков закон

Есть определенные типы данных, которые необходимо копировать, потому что ведение записей является требованием закона. Некоторые записи должны вестись, например, в США по требованию Налогового управления (Internal Revenue Service) (касательно налогов) или Государственной комиссии ценных бумаг (Security and Exchange Commission) (касательно владельцев акций). Законы меняются в зависимости от страны, но, в общем и целом, некоторые сведения являются настолько важными, что существуют законодательные требования доступности таких данных и, возможно, личной ответственности служащих фирмы или кого­либо еще за непринятие соответствующих действий.

Создавайте резервные копии, потому что это вопрос жизни и смерти

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

Не так обстояло дело в нашей прежней жизни. Я работал над системой баз данных для карманных компьютеров, которая позволяла медсестрам вводить информацию о состоянии пациента, включая то, что называлось «вливания и выделения» (inputs and outputs) — сколько жидкости больной получил и сколько жидкости он выделил.

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

Какое количество резервных копий можно считать достаточным?

Одна из особенностей резервного копирования баз данных заключается в том, что данные, труднее всего поддающиеся резервному копированию (данные, которые появляются в последние несколько минут), являются именно теми данными, потеря которых наиболее вероятна. Рис. 1 демонстрирует связь между новизной данных и вероятностью их потери.

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

Вы действительно создаете резервные копии?

Недавно я работал над проектом, в котором требовалось управлять огромным количеством Word­документов. Эти файлы могли бы храниться в самой базе данных, но вместо этого они хранились в файловой системе. Файлы передавались в систему для управления посредством надежного FTP­соединения, и имя файла содержало всю информацию, необходимую для индексирования этого документа, что в результате приводило к использованию очень длинных имен файлов.

Во время тестирования я с радостью увидел, что для этой базы данных было предусмотрено надлежащее резервное копирование. Моей радости поубавилось, когда я обнаружил, что файлы Word­документов, необходимые для корректной работы системы, копировались на DVD­диски и в ходе этого процесса имена файлов искажались и обрезались. Искаженные имена файлов отличались от тех, которые хранились в базе данных, и, следовательно, программа не в состоянии была бы найти документы в восстановленной системе. В итоге, хотя база данных и имела соответствующую резервную копию, система оказалась бы неработоспособной с восстановленными файлами Word­документов.

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

Далее: что именно представляет собой резервное копирование и как это делается?

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

Стратегии сохранения доступности данных

Это вторая статья из серии, посвященной изучению основных аспектов резервного копирования сервера SQL Server. В этой статье рассмотрены различные технологии, гаранти­рующие защиту данных, а также рассказано о том, какая защита является достаточно надежной.

В первой статье этой серии я писал о причинах — начиная с возможности потери вами работы и заканчивая крахом фирмы или необходимостью подчиняться закону — создания резервных копий данных вообще и резервирования данных сервера SQL Server в частности.

К сожалению, резервное копирование для сервера SQL Server — это гораздо более трудное дело в сравнении с тем, к чему мы привыкли. Некогда лишь немногие организации, такие как больницы или полицейские участки, выдвигали требование о том, чтобы приложения функционировали 24 часа в сутки, семь дней в неделю. Сегодня это требование имеют многие организации.

Недавно я помогал заказчику выполнить операцию, которая требовала, чтобы база данных веб­сайта хотя бы 15 минут в день находилась в офлайновом режиме. Эта фирма занимается электронной коммерцией в минимальном объеме, и фактически все ее клиенты находятся в Соединенных Штатах. Я был потрясен, когда, просматривая журналы веб­сайта, увидел, что хотя сайт находился в намного более спокойном состоянии в период между, скажем, 3 и 4 часами утра по восточноевропейскому времени, он никоим образом не был мертв в это время. В этот период по­прежнему имели место сотни тысяч обращений к сайту. Эти люди когда­нибудь спят?

Из­за того, что серверы SQL Server часто работают 24 часа в сутки, одной­единственной резервной копии, полученной в течение дня во время затишья в работе, было бы недостаточно. Но какой объем резервного копирования является достаточным? Слышу, как вы говорите: «У меня очень важные данные, я не могу допустить простоя!». Но, прежде чем вы откажетесь допустить какой­либо простой или какую­либо потерю данных, подумайте о том, что невероятно трудно обеспечить 100­процентную гарантию того, что вы никогда не потеряете никаких данных или у вас никогда ни при каких обстоятельствах не случится авария.

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

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

Что плохого может произойти?

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

Данные, удаленные по ошибке или в результате злонамеренных действий

В большинстве случаев, когда у меня возникала по­требность восстановить данные, причиной проблемы прямо или косвенно являлся я сам. Недавно я исполнял запрос, чтобы восстановить рабочую базу данных. Имелась ошибка, вызвавшая появление нескольких дубликатов записей. Я исполнил SELECT­часть этого запроса (ту часть, которую я использовал бы в опции NOT IN() в предложении DELETE) и получил набор строк, который посчитал правильным. Затем я использовал эту выборку в качестве опции NOT IN() для update­предложения, и поскольку не сомневался в корректности составленного запроса, то не стал, как почти всегда делаю, исполнять этот запрос как часть транзакции с последующими командами COMMIT или ROLLBACK, в зависимости от ситуации. Я щелкнул мышью по маленькой зеленой стрелке в приложении Query Analyzer и к ужасу своему увидел, что удалил все строки в таблице! Я использовал ошибочное поле для предиката WHERE в предложении SELECT в опции NOT IN() и таким образом сформировал запрос, который удалял все.

К счастью, у меня была резервная копия и мне удалось восстановить данные с некоторыми незначительными повреждениями.

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

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

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

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

Сбой аппаратуры

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

Во­первых, существует всегда актуальная проблема сбоя диска. Скорость вращения жестких дисков лежит в пределах от 5 000 до 15 000 оборотов в минуту. При механическом движении такого рода неприятности могут возникнуть быстро. Менее вероятен сбой контроллера жесткого диска или материнской платы. В любом случае вы, по всей вероятности, не сможете добраться непосредственно до данных, находящихся на таком жестком диске. Именно в этом случае критичным оказывается наличие резервных копий на другом физическом томе, если не на другом устройстве или сменном устройстве хранения данных.

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

Аварийный сбой сайта

Сценарий, приводящий к наибольшим разрушениям, часто является таким, о котором вспоминают в последнюю очередь. В книге «Microsoft SQL Server 2000 Unleashed» такого рода авария называется «the Scud test» (Scud­тест, от названия советской тактической ракеты времен холодной войны. — Прим. ред.). Если ракета попадет в ваше здание, сможет ли уцелеть ваша база данных или даже ваш бизнес? Хотя еще пять лет назад это могло быть абстрактным предположением, в момент написания данной статьи я нахожусь менее чем в 60 милях от того места, где некогда стояли башни Всемирного торгового цен­тра (World Trade Center, WTC). Помимо неоспоримых человеческих жертв, многие предприятия, пережившие 11 сентября, обнаружили, что их данные пропали. Выборочные примеры некоторых фирм, затронутых WTC­катастрофой, вместе с информацией о том, насколько хорошо работала их служба планирования, вы можете найти по адресу: http://www.business2.com/b2/web/articles/0,17863,514202,00.html. Последствия лежат в диапазоне от «фактически никаких потерь» до «полная потеря всех данных». С 2001 года многие внесенные в планы резервного копирования усовершенствования, которые были инициированы событиями 11 сентября, нашли свое применение в столкновениях с такими явлениями, как пожары, ураганы и наводнения.

Более обыденными, но столь же разрушительными могут быть аварийные сбои в подаче электроэнергии или обрывы связи. Один мой заказчик удачно переместил всю свою базу данных и все веб­серверы с сайта общего пользования на внутрифирменный сайт только для того, чтобы вернуть их обратно после сбоя в подаче электроэнергии, который продолжался 36 часов и «выбросил» фирму из Интернета. Хотя удалось быстро наладить питание серверов, чтобы выполнить копирование базы данных и приложений, у фирмы не оказалось подходящего способа, чтобы вернуть эти данные обратно в веб­среду.

Насколько удобным окажется доступ к вашим хранящимся в другом месте резервным копиям в случае аварийного сбоя в работе сайта? Сколько труда потребуется для того, чтобы заново восстановить ваши машины (все машины), если у вас нет ничего, с чего можно было бы начать?

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

Итак, что же такое резервное копирование на самом деле?

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

Наилучший способ обеспечить резервное копирование — предотвратить потери. Вы по большей части не можете предотвратить аварийные сбои в работе сайтов, но можете смягчить последствия менее значительных сбоев, обеспечивая множество источников бесперебойного питания и избыточный интернет­доступ (redundant Internet access). В случае пожара, наводнения, урагана или атаки террористов вам, вероятно, следует полагаться на резервные копии.

Далее: создание фундамента для предотвращения потерь данных

Надлежащим образом настроенная аппаратура — это первый шаг на пути обеспечения защиты ваших данных. Решения, которые вы принимаете, когда выбираете аппаратуру и настраиваете базу данных, могут сделать из вас героя в области баз данных (и даже, может быть, очередного Заклинателя баз данных недели (Database Geek of the Week) или превратить вас в козла отпущения, если все пойдет не так, как надо. Ваш среднестатистический специалист по аппаратуре не знаком с сервером SQL Server, а ваш среднестатистический администратор базы данных не знает «железа». Понимание в достаточной степени обоих миров может обеспечить существенное различие в конечном итоге.

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

Минимизация потребностей в восстановлении резервной копии

Это третья статья из серии, посвященной изучению основных аспектов резервного копирования сервера SQL Server. Эта статья объясняет, как сконфигурировать вашу аппаратуру таким образом, чтобы минимизировать потребности в восстановлении резервной копии.

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

Получение «правильной» аппаратуры

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

Задумайтесь на минуту о вашем среднестатистическом, обычном, низкоуровневом сервере. Он мог бы иметь от одного до двух жестких дисков и один или два источника бесперебойного питания. Если сервер SQL Server устанавливается с настройками, предусмотренными по умолчанию, тогда все программы, данные и журналы находятся на одном и том же диске, в одной и той же папке (они находятся в папке Program Files, что, как мне кажется, небез­опасно).

Сколько отдельных источников сбоя вы имеете в случае установки по умолчанию? Во­первых, сбой или одного жесткого диска, или одного устройства бесперебойного питания вызовет остановку сервера, по крайней мере временно. В случае сбоя жесткого диска вам необходимо будет получить новый диск, заново инсталлировать сервер SQL Server и восстановить резервные копии. На это уйдет некоторое время.

Есть несколько вещей, которые вы можете сделать, чтобы уменьшить такую возможную открытость перед лицом аварийной потери данных. Во­первых, необходимо рассмотреть возможность приобретения сервера, который имеет хотя бы два источника бесперебойного питания. Источник питания — это довольно распространенный объект сбоя, и зачастую наличие избыточных источников питания повышает стоимость системы всего лишь на сумму примерно в $250. Это хорошее вложение денег.

Путь к самодокументируемой базе данных SQL Server

Расширенные свойства — это одно из множества разнообразных средств, гарантирующих, что ваши базы данных хорошо документированы и легко понимаемы.

Расширенные свойства в SQL Server

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

Возможность, которая попадает в первую категорию, — расширенные свойства баз данных. Представленные без излишнего шума в версии SQL Server 2000, они легко могли бы оказаться упущенными из виду, но в конечном итоге доказали свою большую ценность для разработчика. Расширенные свойства — это дорога к созданию баз данных с самодокументированием. Я использую термин «самодокументирование» в том смысле, что такую документацию можно «привязать» непосредственно к самой базе данных, вместо того чтобы создавать отдельный документ. По сути дела, вы используете расширенные свойства объектов данных, чтобы применить ваши собственные свойства для метаданных.

Резервное копирование баз данных — шпаргалка

Не о том, что вам любопытно узнать, а о том, что вам знать необходимо

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