126. Режимы передачи информации: сущность, оценка, области изменения.

Для передачи сообщений в вычислительных сетях используются различные типы каналов связи. Наиболее распространены выделенные телефонные каналы и специальные каналы для передачи цифровой информации. Применяются также радиоканалы и каналы спутниковой связи.

Существуют три режима передачи: симплексный, полудуплексный и дуплексный.

В сетях связи нашли применение следующие режимы передачи информации:

- симплексные, когда передатчик и приемник связываются одним каналом связи, по которому информация передается только в одном направлении (это характерно для телевизионных сетей связи);

- полудуплексные, когда два узла связи соединены также одним каналом, по которому информация передается попеременно то в одном направлении, то в противоположном (это характерно для информационно-справочных, запрос-ответных систем);

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

127. Резервное копирование. Типы резервного копирования sql Server 2000.

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

Администратор SQL Server 2000 имеет в своем распоряжении множество средств обеспечения надежности системы:

- резервное копирование данных и журнала транзакций;

- использование резервного сервера;

- создание кластеров;

- возможности технологий RAID (технология дублирования, зеркального отображения и чередования с контролем четности), предназначенные для обеспечения отказоустойчивости дисковых масси­вов.

Каждое из приведенных средств имеет свои недостатки и преимущества. Например, технологии RAID (Redundant Array of Independent Disks) обеспечивают работоспособность системы в случае небольших сбоев в функционировании дисковой системы, но при выходе из строя всего компьютера на помощь прихо­дит резервный сервер или кластер. Когда же все серверы повреждены и нет возможности восстановить данные ни с одного из них, то остается лишь обра­титься к резервной копии.

Упомянутые средства обеспечения надежности системы не исключают друг друга. Наоборот, желательно применять их совместно. Например, информационная система предприятия может работать на главном сервере со­вместно с резервным, и на каждом из них может использоваться чередование дисков с контролем четности. Кроме того, необходимо периодически создавать резервную копию данных, чтобы иметь возможность восстановить информацию при выходе из строя обоих серверов баз данных (например, в случае пожара или природного катаклизма).

Резервное копирование (back up) является одним из самых надежных способов защиты данных от потери. Технологии RAID обеспечивают функционирование системы при выходе из строя одного из жестких дисков или даже дискового контроллера. Но они бессильны в случае выхода из строя оперативной памяти центрального процессора или сетевой карты. В этом случае пользователи не смогут получить с сервера данные. Решением проблемы будет использование резервного сервера или кластера. Но предположим, что информация на всех серверах была уничтожена. Чтобы иметь возможность восстановить данные, не­обходимо иметь полную их копию. Такая копия данных называется резервной (backup), и ни пользователи, ни система не имеют к ней доступа. Не­обходимо отметить, что резервная копия имеет значительно меньший размер по сравнению с исходной базой данных. Процесс создания резервной копии также называют архивированием.

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

Часто архивирование используется для переноса баз данных между серверами SQL Server 2000. База данных архивируется на исходном сервере на какой-нибудь носитель, который затем рассылается на другие серверы. На удаленном сервере администратор восстанавливает базу данных и может успешно с ней работать.

Если база данных имеет большой размер и интенсивно обновляется, то процесс создания резервной копии всех данных может занять очень много времени. Кроме того, если при создании резервной копии пользователи продолжают работать с данными, то к моменту завершения резервирования уже скопирован­ные данные могут быть изменены, что способно привести к нарушению целост­ности информации. Во избежание подобных проблем SQL Server 2000 автоматически отслеживает изменения в уже скопированных данных и обновляет их. Однако если резервирование длится слишком долго, то пользователи не смогут полноценно работать с данными. Необходимо каким-либо образом сократить время архивирования, гарантируя при этом полноту резервной копии.

SQL Server 2000 поддерживает различные типы резервного копирования, позволяя администратору очень гибко управлять данным процессом. Существует полная копия; разностная копия; копия журнала транзакций; резервное копирование файлов и групп файлов.

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

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

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

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

- создание и удаление файлов базы данных;

- создание индексов;

- выполнение операций, не регистрируемых в журнале транзакций, и др.

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

Разностное, или дифференциальное, резервное копирование (differential database backup) было разработано с целью уменьшения времени, необходимого для по­лучения копии базы данных. В основе дифференциальной копии лежит отсле­живание изменений, вносимых пользователями в базу данных. Создание диф­ференциальной копии состоит из двух этапов: создание полной копии данных; создание собственно дифференциальной копии.

Полная копия базы данных является отправной точкой, начиная с которой сис­тема может отслеживать изменения. Изменения отслеживаются на уровне стра­ниц. Каждая страница имеет флаг архивирования, который сбрасывается при создании полной копии и устанавливается, если данные на странице были из­менены. Это можно сравнить с атрибутом архивирования для файлов. При соз­дании резервной копии атрибут снимается, но если файл изменяется, то систе­ма автоматически устанавливает его. Программа резервного копирования ищет все файлы с установленным атрибутом архивирования и копирует их. Аналогично ведет себя и подсистема резервного копирования SQL Server 2000. Однако необходимо отметить, что флаг архивирования для страниц данных снимается только при создании полной копии данных. Это означает, что при создании последовательно нескольких дифференциальных копий каждая следующая будет полностью включать страницы, которые были включены в предыдущую копию, плюс все страницы, измененные со времени создания предыдущей копии. По­этому актуальна только самая последняя дифференциальная копия. Достаточно применить ее после восстановления полной резервной копии, чтобы целиком восстановить систему.

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

Копия журнала транзакций

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

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

Решением подобных проблем является применение резервного копирования жур­нала транзакций (transaction log backup). Этот тип резервного копирования позволяет сохранять информацию обо всех транзакциях, выполненных в базе дан­ных. В итоге резервная копия содержит непрерывную цепочку изменений, которые претерпели данные со времени последнего архивирования. Такая цепочка позволяет восстановить систему в состоянии, в котором она была в любой мо­мент времени и этот момент отображен в резервной копии. При восстановле­нии резервной копии журнала транзакций SQL Server 2000 последовательно вы­полняет все изменения, выполненные пользователями в базе данных.

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

Резервное копирование файлов и групп файлов

Это последний из типов резервного копирование SQL Server 2000. Как известно, база данных состоит из одного или более файлов данных и одного или более файлов журнала транзакций. Иными словами, любая база данных состоит минимум из двух файлов. Ни полное, ни резервное копирование не позволяют архивиро­вать только часть данных, например, только данные без индексов или только столбцы типа image, text и ntext. Резервная копия журнала транзакции ото­бражает лишь операции изменения данных.

SQL Server 2000 позволяет выполнять частичное архивирование данных. Для этого администратор должен использовать копирование файлов или групп файлов. Такой подход позволяет контролировать диапазон архивируемых данных вплоть до конкретного столбца таблицы. В основе этого подхода лежит возмож­ность привязывания таблицы или даже отдельного столбца к конкретному фай­лу или группе файлов. Все данные, принадлежащие столбцу, будут размешаться только в указанном файле или группе файлов. Обычно к файлу или группе фай­лов привязываются либо таблицы целиком, либо столбцы с типом данных im­age, text и ntext, требующие значительных ресурсов для их обработки.