2.2.6 Оптимизатор выполнения запросов по стоимости
Оптимизатор запросов определяет наиболее оптимальный с точки зрения затрат системных ресурсов план реализации каждого запроса к базе данных. Учитывается число обменов с диском, затраты разделяемой памяти, затраты на пересылку данных по сети и др. План может включать параллельное выполнение операций или быть строго последовательным, что зависит как от структуры запроса, так и от ресурсов, выделяемых MGM. Оптимизатор опирается на статистическую информацию о распределении данных по столбцам таблиц, периодическим сбором которой управляет администратор.
Например, если требуется выполнить соединение двух таблиц, находящихся в разных узлах сети, то оптимизатор спланирует эту операцию таким образом, что меньшая по объему таблица будет передана на сервер, содержащий большую таблицу, где и будет выполнено соединение (не обязательно выполнять его на том сервере, к которому произведено первое подключение). Дополнительная оптимизация достигается за счет фильтрации таблицы перед ее пересылкой, т. е. изъятия из нее не участвующих в данной операции соединения строк и/или столбцов.
Оптимизатор дает возможность разработчику предварительно получить план выполнения запроса, в том числе, распределенной транзакции. Получив такой план, разработчик может выяснить, что не располагает достаточной памятью, чтобы сохранить полученные в результате данные, или что выполнение запроса потребует слишком больших затрат системных ресурсов. В такой ситуации он либо отложит выполнение запроса на другое время, либо переформулирует запрос так, чтобы сузить объем возвращаемых данных, либо примет какое-то другое решение.
Прикладной программист или пользователь устанавливает один из двух возможных уровней оптимизации - высокий или низкий. Высокий уровень оптимизации предполагает перебор большого числа возможных вариантов и сам требует больших затрат системных ресурсов, в частности, памяти. Оптимизация низкого уровня обходится дешевле, поскольку перебирается небольшое число предположительно оптимальных вариантов, но остается вероятность "упустить" наилучший вариант. Например, план выполнения хранимой процедуры вычисляется заранее с высоким уровнем оптимизации и сохраняется, после чего устанавливается низкий уровень - тогда при обращении к процедуре используется построенный заранее наиболее оптимальный план.
2.2.7 Средства обеспечения надежности
Сервер INFORMIX-OnLine DS предоставляет следующие средства для восстановления после сбоев и обеспечения отказоустойчивости:
Зеркалирование дисковых областейПолное тиражирование данных сервераБыстрое восстановление при включении системыСредства архивирования данных
2.2.7.1 . Зеркалирование дисковых областей
Зеркалирование в INFORMIX-OnLine DS - это дублирование связной дисковой области, выделенной под базу данных, на такую же по размеру область. Исходная область называется первичной, а ее копия - зеркальной. Цели, для которых применяется зеркалирование - высокая готовность и оптимизация операций чтения.
Высокая готовность достигается за счет того, что при выходе из строя диска, на котором находится первичная область, сервер автоматически продолжает работу с оставшимся диском без перехода сервера в режим off-line. Все операции чтения-записи происходят с зеркальной областью (при условии, что она находится на другом диске). Восстановление копии на первичном диске после его включения производится в оперативном режиме.
Затраты на зеркалирование складываются из затрат дискового пространства и затрат на дополнительные операции записи. В условиях, когда имеется несколько виртуальных процессоров обмена с диском, операции записи на оба диска производятся параллельно, и затраты второго рода сводятся к минимуму. К тому же они компенсируются оптимизацией операций чтения, о которой говорится ниже.
В идеальном случае зеркалирование должно быть обеспечено для всех областей базы данных. Крайне желательно поддерживать зеркалирование для критичных областей, составляющих корневое пространство базы данных и пространства, где хранятся логический и физический журналы. При выходе из строя любого из них, если нет зеркального дубля, сервер немедленно переводится в режим off-line. При отказе других незеркалируемых областей недоступными становятся только хранящиеся на них таблицы или фрагменты таблиц - до завершения процедуры их восстановления. Поэтому для наиболее критичных таблиц также желательно поддерживать зеркалирование.
