Математическое обеспечение и администрирование информационных систем

|     ...       |

+---------------+

|010101010101010|

|010101010101010|

|010101010101010| <---- данные

|010101010101010|

|010101010101010|

+---------------+

 

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

Теперь, получив общее представление  о сегментах, состоящих из экстентов, которые, в свою очередь, состоят из блоков, можно переходить к понятию "табличное пространство" и разбираться, где же в этой структуре место для файлов. Табличное пространство — это контейнер с сегментами. Каждый сегмент принадлежит к одному табличному пространству. В табличном пространстве может быть много сегментов. Все экстенты сегмента находятся в табличном пространстве, где создан сегмент. Сегменты никогда не переходят границ табличного пространства. С табличным пространством, в свою очередь, связан один или несколько файлов данных. Экстент любого сегмента табличного пространства целиком помещается в одном файле данных. Однако экстенты сегмента могут находиться в нескольких различных файлах данных. Графически это можно представить следующим образом¹¹:

...

Итак, здесь представлено табличное пространство USER_DATA. Оно состоит из двух файлов данных — user_data01 и user_data02. В нем выделено три сегмента: T1, T2 и I1 (вероятно, две таблицы и индекс). В табличном пространстве выделены четыре экстента, причем каждый показан как непрерывный набор блоков базы данных. Сегмент T1 состоит из двух экстентов (по одному экстенту в каждом файле). Сегменты T2 и I1 состоят из одного экстента. Если для табличного пространства понадобится больше места, можно либо увеличить размер файлов данных, уже выделенных ему, либо добавить третий файл данных.

Табличные пространства в Oracle — это  логические структуры хранения данных. Разработчики создают сегменты в  табличных пространствах. Они никогда  не переходят на уровень файлов —  нельзя указать, что экстенты должны выделяться из определенного файла. Объекты создаются в табличных пространствах, а об остальном заботится сервер Oracle. Если в дальнейшем администратор базы данных решит перенести файлы данных на другой диск для более равномерного распределения операций ввода-вывода по дискам, никаких проблем для приложения это не создаст. На работе приложения это никак не отразится.

Итак, иерархия объектов, обеспечивающих хранение данных в Oracle, выглядит так.

1. База данных, состоящая из одного или нескольких табличных пространств.
2. Табличное пространство, состоящее из одного или нескольких файлов данных. Табличное пространство содержит сегменты.
3. Сегмент (TABLE, INDEX и т.д.), состоящий из одного и более экстентов. Сегмент привязан к табличному пространству, но его данные могут находиться в разных файлах данных, образующих это табличное пространство.
4. Экстент — набор расположенных рядом на диске блоков. Экстент целиком находится в одном табличном пространстве и, более того, в одном файле данных этого табличного пространства.
5. Блок — наименьшая единица управления пространством в базе данных. Блок — наименьшая единица ввода-вывода, используемая сервером.

Прежде чем завершить описание файлов данных, давайте разберемся, как происходит управление экстентами в табличном пространстве. До версии 8.1.5 в Oracle был только один метод управления выделением экстентов в табличном пространстве. Этот метод называется управление табличным пространством по словарю. Т.е. место в табличном пространстве отслеживается в таблицах словаря данных (аналогично тому, как отслеживаются движения средств на банковских счетах с помощью пары таблиц DEBIT и CREDIT). В качестве дебета можно рассматривать выделенные объектам экстенты, в качестве кредита — свободные для использования экстенты. Когда для объекта необходим очередной экстент, он запрашивается у системы. При получении такого запроса сервер Oracle обращается к соответствующим таблицам словаря данных, выполняет ряд запросов, находит (или не находит) свободное место нужного размера, а затем изменяет строку в одной таблице (или удаляет ее) и вставляет строку в другую. При этом сервер Oracle управляет пространством примерно так же, как работают обычные приложения: он изменяет данные в таблицах.

Соответствующие SQL-операторы для получения дополнительного пространства, выполняемые в фоновом режиме от имени пользователя, называют рекурсивными. Выполненный пользователем SQL-оператор INSERT вызывает выполнение других рекурсивных SQL-операторов для получения пространства на диске. При частом выполнении рекурсивные SQL-операторы создают весьма существенную дополнительную нагрузку на систему. Подобные изменения словаря данных должны выполняться последовательно, делать их одновременно нельзя. По возможности их следует избегать.

В прежних  версиях Oracle этот метод управления пространством (и связанные с ним дополнительные расходы ресурсов на выполнение рекурсивных SQL-операторов) приводил к проблемам при работе с временными табличными пространствами (до появления "настоящих" временных табличных пространств). Речь идет о табличных пространствах, в которых необходимо часто выделять место (при этом надо удалить строку из одной таблицы словаря данных и вставить в другую) и освобождать его (помещая только что перенесенные строки туда, где они ранее были). Эти операции выполняются последовательно, что существенно снижает возможности одновременной работы и увеличивает время ожидания. В версии 7.3 СУБД Oracle для решения этой проблемы добавили временные пространства. Во временном табличном пространстве пользователь не мог создавать постоянные объекты. Это было единственным новшеством: управление пространством все равно выполнялось с помощью таблиц словаря данных. Однако после выделения экстента во временном табличном пространстве система его уже не освобождала. При следующем запросе экстента из временного табличного пространства сервер Oracle искал уже выделенный экстент в соответствующей структуре данных в памяти и, найдя, использовал повторно. В противном случае экстент выделялся как обычно. При этом после запуска и работы СУБД в течение некоторого времени соответствующий временный сегмент выглядел как заполненный, но фактически был просто "выделен". Свободными экстентами в нем управляли по-другому. При запросе сеансом временного пространства сервер Oracle искал его в структурах данных в памяти, а не выполнял дорогостоящие рекурсивные SQL-операторы.

В версиях Oracle, начиная с 8.1.5, был сделан следующий  шаг по сокращению расхода ресурсов на управление пространством. Кроме  табличных пространств, управляемых  по словарю данных, появились локально управляемые табличные пространства. Для всех табличных пространств стало можно делать то, что в Oracle 7.3 делалось для временных, т.е. не использовать словарь данных для управления свободным местом в табличном пространстве. В локально управляемом табличном пространстве для отслеживания экстентов используется битовая карта, хранящаяся в каждом файле данных. Теперь для получения экстента достаточно установить значение 1 для соответствующего бита в битовой карте. Для освобождения экстента — сбросить бит обратно в 0. По сравнению с обращениями к словарю данных, это выполняется молниеносно. Больше не требуется ждать завершения длительно выполняемой операции, на уровне базы данных последовательно выделяющей место во всех табличных пространствах. Очередность на уровне табличного пространства остается только для очень быстро выполняемой операции. Локально управляемые табличные пространства имеют и другие положительные качества, например устанавливают одинаковый размер всех экстентов, но это имеет значение только для администраторов баз данных.

2.3.3. Временные файлы

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

Сервер Oracle обрабатывает временные файлы специальным  образом. Обычно все изменения объектов записываются в журналы повторного выполнения. Эти журналы транзакций в дальнейшем можно использовать для повторного выполнения транзакций. Это делается, например, при восстановлении после сбоя. Временные файлы в этом процессе не участвуют. Для них не генерируются данные повторного выполнения, хотя и генерируются данные отмены (UNDO) при работе с глобальными временными таблицами, чтобы можно было откатить изменения, сделанные в ходе сеанса. Создавать резервные копии временных файлов данных нет необходимости, а если кто-то это делает, то напрасно теряет время, поскольку данные во временном файле восстановить все равно нельзя.

Рекомендуется конфигурировать базу данных так, чтобы  временные табличные пространства управлялись локально. Убедитесь, что  ваш администратор базы данных использует команду CREATE TEMPORARY TABLESPACE. Никому не нужно еще одно обычное табличное пространство, используемое под временные данные, поскольку не удастся получить преимущества временных файлов данных. Убедитесь также, что в качестве временного используется локально управляемое табличное пространство с экстентами одинакового размера, соответствующего значению параметра инициализации sort_area_size. Создаются такие временные табличные пространства примерно так:

 

tkyte@TKYTE816> create temporary tablespace temp

  2  tempfile 'c:\oracle\oradata\tkyte816\temp.dbf'

  3  size 5m

  4  extent management local

  5  uniform size 64k;

 

Tablespace created.

 

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

2.3.4. Управляющие файлы

Управляющий файл — это сравнительно небольшой файл (в редких случаях он может увеличиваться до 64 Мбайт), содержащий информацию обо всех файлах, необходимых серверу Oracle. Из файла параметров инициализации (init.ora) экземпляр может узнать, где находятся управляющие файлы, а в управляющем файле описано местонахождение файлов данных и файлов журнала повторного выполнения. В управляющих файлах хранится и другие необходимые серверу Oracle сведения, в частности время обработки контрольной точки, имя базы данных (которое должно совпадать со значением параметра инициализации db_name), дата и время создания базы данных, хронология архивирования журналов повторного выполнения (именно она приводит к увеличению размера управляющего файла в некоторых случаях) и т.д.

Управляющие файлы надо мультиплексировать либо аппаратно (располагать на RAID-массиве), либо с помощью средств сервера Oracle, когда RAID-массив или зеркалирование использовать нельзя. Необходимо поддерживать несколько копий этих файлов, желательно на разных дисках, чтобы предотвратить потерю управляющих файлов в случае сбоя диска. Потеря управляющих файлов — не фатальное событие, она только существенно усложнит восстановление.

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

2.3.5. Файлы журнала повторного выполнения

Файлы журнала повторного выполнения принципиально важны для базы данных Oracle. Это журналы транзакций базы данных. Они используются только для восстановления при сбое экземпляра или носителя или при поддержке резервной базы данных на случай сбоев. Если на сервере, где работает СУБД, отключится питание и вследствие этого произойдет сбой экземпляра, для восстановления системы в состояние, непосредственно предшествующее отключению питания, сервер Oracle при повторном запуске будет использовать оперативные журналы повторного выполнения. Если диск, содержащий файлы данных, полностью выйдет из строя, для восстановления резервной копии этого диска на соответствующий момент времени сервер Oracle, помимо оперативных журналов повторного выполнения, будет использовать также архивные. Кроме того, при случайном удалении таблицы или какой-то принципиально важной информации, если эта операция зафиксирована, с помощью оперативных и архивных журналов повторного выполнения можно восстановить данные из резервной копии на момент времени, непосредственно предшествующий удалению.

Практически каждое действие, выполняемое  в СУБД Oracle, генерирует определенные данные повторного выполнения, которые надо записать в оперативные файлы журнала повторного выполнения. При вставке строки в таблицу конечный результат этой операции записывается в журналы повторного выполнения. При удалении строки записывается факт удаления. При удалении таблицы в журнал повторного выполнения записываются последствия этого удаления. Данные из удаленной таблицы не записываются, но рекурсивные SQL-операторы, выполняемые сервером Oracle при удалении таблицы, генерируют определенные данные повторного выполнения. Например, при этом сервер Oracle удалит строку из таблицы SYS.OBJ$, и это удаление будет отражено в журнале.

Некоторые операции могут выполняться  в режиме с минимальной генерацией данных повторного выполнения. Например, можно создать индекс с атрибутом NOLOGGING. Это означает, что первоначальное создание этого индекса не будет записываться в журнал, но любые инициированные при этом рекурсивные SQL-операторы, выполняемые сервером Oracle, — будут. Например, вставка в таблицу SYS.OBJ$ строки, соответствующей индексу, в журнал записываться не будет. Однако последующие изменения индекса при выполнении SQL-операторов INSERT, UPDATE и DELETE, будут записываться в журнал.

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

 

 

Тема 3. Администрирование  в среде Unix.

3.1. Включение станции Sun SPARCstation.

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

 

Console login:

 

а на всех остальных терминалах - просто:

 

Login:

 

Введите свой входной login, и пароль. Если таковых не существует, войдите под login'ом root - "суперпользователь" - изначально он не имеет пароля.

 

Console login: root

 

Процесс нормальной работы Sun SPARCstation в любой момент времени можно  перехватить, и передать управление на boot-prom. Для этого на системной клавиатуре нажмите STOP+A. (STOP - левая верхняя клавиша на левой дополнительной клавиатуре). Появится boot-prom prompt Ok:

 

Ok _

 

Теперь можно вводить команды  для boot-монитора. Пожалуй, наиболее популярными  командами являются:

go	выйти из монитора, вернуться в  нормальный режим
help	Попошь
boot [параметры]	загрузиться
eject	вытолкнуть "застрявший" флоппи-диск или CDROM
probe-scsi	опросить опознанные SCSI-устройства (после этой команды возращаться  к нормальной работе командой "GO" НЕЛЬЗЯ. Перезагрузитесь)