7) Упорядочивание записей выборки:
Данная операция выполняется при наличии фразы ORDER BY.
Она содержит список полей, по которым выполняется упорядочивание. Каждое поле упорядочивания должно присутствовать в выходном списке.
Порядок сортировки определяется порядком следования полей в списке упорядочивания. Сначала выполняется сортировка по первому полю списка, затем внутри каждой сортировочной группы – по второму полю и т.д.
После каждого поля можно указать направление сортировки по этому полю.
Допустимыми значениями указателя сортировки являются ASC (по возрастанию) и DESC (по убыванию).
При использовании фразы UNION упорядочивание может быть задано только однократно. Фраза ORDER BY в этом случае размещается в самом конце и относится ко всему объединению.
Например, следующая инструкция позволяет получить список лучших студентов выпуска 2002 г., средний балл которых больше 4,5:
SELECT Имя, Фамилия
FROM Студенты
WHERE ГодВыпуска =2002
AND СреднийБалл>4.5
ORDER BY СреднийБалл DESC;
13. Восстановление данных
Одним из основных требований к развитым СУБД является надежность хранения баз данных. Это требование предполагает, в частности, возможность восстановления согласованного состояния базы данных после любого рода аппаратных и программных сбоев. Очевидно, что для выполнения восстановлений необходима некоторая дополнительная информация. В подавляющем большинстве современных реляционных СУБД такая избыточная дополнительная информация поддерживается в виде журнала изменений базы данных.
Поскольку основой поддержания целостного состояния базы данных является механизм транзакций, журнализация и восстановление тесно связаны с понятием транзакции.
Средства восстановления не стандартизированы и являются специфичными для разных СУБД. В целом обобщенная схема восстановления имеет вид:
Буфер данных – для временного хранения обрабатываемых данных. Данные записываются в буфер, который находится в ОЗУ. Он может быть как на стороне сервера, так и клиента.
Буфер журнала (операций или транзакций) – для буферирования текущей информации по операциям изменения.
Оперативная база данных – база данных, с которой выполняется работа.
Журнал – хранит историю операций с данными.
Архив данных – хранятся резервные копии оперативной базы данных.
Архив журнала – хранятся сведения об операциях, не требующих оперативной работы.
НОРМАЛЬНЫЙ РЕЖИМ
В нормальном режиме работы с клиентских мест поступают обращения к СУБД, нужные данные загружаются в буфер данных, при выполнении операций с данными действия фиксируются с помощью буфера журнала. Эти действия могут регистрироваться различными способами. Самый простой – записываются все операции. При этом возможно отменять действия. Другой способ – расставляют метки об удалении, тогда при необходимости можно будет восстановить эти записи. При подтверждении изменений делается новая копия, затем удаляются записи, помеченные для удаления.
По ходу работы информация из буферов переносится на диск. Основные ситуации:
1) Буфер данных переписывается на диск при заполнении буфера.
2) Буфер журнала перезаписывается:
- по переполнению буфера.
- по завершению транзакций.
- перед перезаписью данных из буфера данных. Обеспечивается протоколом WAL (Write-Ahead Logging). Данное упреждающее журнализирование является ключевым методом обеспечения требований физической целостности данных. WAL позволяет обеспечить сброс на диск записей из журнала транзакций, относящихся к изменениям данных, раньше того, как будут сброшены на диск сами эти изменённые страницы данных. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя/
Для последующего восстановления используются архивы данных и журнала. Архивация данных может быть по заданным событиям или по явной команде пользователя. При этом копируется вся база или её часть.
В итоге: есть база данных, с которой работаем. Чтобы её не потерять, делается её копия, функция полного копирования обычно есть во всех СУБД. Но эта операция требует монопольного режима работы. Создаваемая копия может быть в другом формате, отличном от формата исходной базы данных. Резервная копия обычно не копирует записи, помеченные на удаление. Копирование может вестись по какому-то событию. Резервное копирование может также позволить перейти в более высокую версию СУБД.
Архивация в архив журнала обычно выполняется для сокращения оперативной части журнала. Архивация выполняется в рабочем режиме. Для этого журнал делится на два блока – один для записи данных из буфера журнала, второй для архивации. После выполнения архивации выполняется смена частей местами. В некоторых системах есть больше частей, это позволяет сгладить пиковые режимы (когда данные не успевают архивироватся). При отсутствии архива журнала реализуется освобождение журнала через архивацию данных, тогда журнал стирается при архивации данных.
СБОЙНЫЕ СИТУАЦИИ
Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:
Индивидуальный откат транзакции. Тривиальной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK. Возможны также ситуации, когда откат транзакции инициируется системой (возникновение исключительных ситуаций в прикладной программе, например, деление на ноль). Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции.
Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть при аварийном выключении электрического питания, при возникновении неустранимого сбоя процессора (например, срабатывании контроля оперативной памяти) и т.д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти.
Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее, СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.
Соответственно трём вариантам сбойных ситуаций существуют три основных вида восстановления:
Восстановление одиночной транзакции.
Для отката транзакции используется буфер журнала и журнал. Для восстановления выполненные операции просматриваются в обратном порядке и выполняются инверсные действия. Например, вместо операции INSERT выполняется соответствующая операция DELETE, вместо DELETE - INSERT, вместо UPDATE - обратная операция UPDATE, восстанавливающая предыдущее состояние объекта базы данных. Любая из этих обратных операций также журнализируется.
2) Восстановление после мягкого сбоя (теряются данные в ОЗУ).
Для восстановления используется журнал. Будем считать, что в журнале отмечаются точки физической согласованности базы данных - моменты времени, в которые во внешней памяти содержатся согласованные результаты операций, завершившихся до соответствующего момента времени, и отсутствуют результаты операций, которые не завершились, а буфер журнала вытолкнут во внешнюю память. Тогда к моменту мягкого сбоя возможны следующие состояния транзакций:
Предположим, что некоторым способом удалось восстановить внешнюю память базы данных к состоянию на момент времени tlpc. Тогда:
Для транзакции T1 никаких действий производить не требуется. Она закончилась до момента tlpc, и все ее результаты отражены во внешней памяти базы данных.
Для транзакции T2 нужно повторно выполнить оставшуюся часть операций, поскольку во внешней памяти полностью отсутствуют следы операций, которые выполнялись после момента tlpc, но в журнале содержатся записи обо всех изменениях, произведенных этой транзакцией до момента мягкого сбоя.
Для транзакции T3 нужно выполнить в обратном направлении первую часть операций, поскольку во внешней памяти базы данных полностью отсутствуют результаты операций, которые были выполнены после момента tlpc, но гарантированно присутствуют результаты операций T3, которые были выполнены до этого момента. Следовательно, обратная интерпретация операций T3 приведет к согласованному состоянию базы данных (поскольку транзакция T3 не завершилась к моменту мягкого сбоя, при восстановлении необходимо устранить все последствия ее выполнения).
Для транзакции T4, которая успела начаться после момента tlpc и закончиться до момента мягкого сбоя, нужно выполнить полную повторную прямую интерпретацию операций.
Наконец, для начавшейся после момента tlpc и не успевшей завершиться к моменту мягкого сбоя транзакции T5 никаких действий предпринимать не требуется. Результаты операций этой транзакции полностью отсутствуют во внешней памяти базы данных.
Рассмотренные варианты можно графически представить следующим образом:
3) Восстановление после жесткого сбоя (теряется база данных на диске).
Основой восстановления в этом случае являются журнал и архивная копия базы данных.
Восстановление начинается с обратного копирования базы данных из архивной копии. Затем для всех закончившихся транзакций операции повторно выполняются в прямом смысле, в соответствии с архивом журнала. Если есть журнал, то выполняются операции по журналу. Для транзакций, которые не закончились к моменту сбоя, выполняется откат.
Для успешного восстановления данных необходимо хранение блоков на разных носителях, причем журналы желательно хранить на съемных дисках.
Данная схема восстановления реализуется в разном объеме, в зависимости от функциональности СУБД:
1) восстановление невозможно, если СУБД этого не поддерживает (отсутствуют архивы данных, буфер журнала, журнал и архив журнала):
2) система поддерживает создание резервных копий:
Простая система, вести журналов не нужно. Но создание архивных копий требует много времени.
3) практически полная система восстановления:
4) полная реализация:
Как часто требуется производить архивные копии базы данных? Самый простой способ - архивировать базу данных при переполнении журнала. В журнале вводится так называемая "желтая зона", при достижении которой образование новых транзакций временно блокируется. Когда все транзакции закончатся, и, следовательно, база данных придет в согласованное состояние, можно производить ее архивацию, после чего начинать заполнять журнал заново.
ДОПОЛНИТЕЛЬНЫЕ СРЕДСТВА ВОССТАНОВЛЕНИЯ:
1) Зеркалирование – параллельно пишется зеркальная копия базы. Основная база – на основном диске, но то же самое одновременно пишется на второй, дополнительный диск. Достоинство – быстрое восстановление, недостаток – невозможность выполнения откатов.
2) Аппаратное резервирование, например, с использованием RAID-массивов. Это массив из нескольких дисков (запоминающих устройств), управляемых контроллером, связанных между собой скоростными каналами передачи данных и воспринимаемых внешней системой как единое целое. В зависимости от типа используемого массива может обеспечивать различные степени отказоустойчивости и быстродействия. Служит для повышения надёжности хранения данных и/или для повышения скорости чтения/записи.