omf формат что это

OMF еще послужит

Речь пойдет о том OMF, который Relocatable Object Module Format, поскольку есть и другие вещи с той же аббревиатурой. Вероятно, первоначально этот формат был разработан Intel (Intel Technical Specification 121748-001), а потом его приняли и использовали и IBM и Microsoft. Это формат объектных модулей (OBJ), в котором записывали результаты своей работы различные трансляторы, а затем различные редакторы связей в соответствии с OMF собирали исполняемые программы в течение многих десятилетий.

Помню, что когда переводил свою систему программирования из 16-ти разрядной среды MS-DOS в 32-х разрядную, казалось, что потребуются значительные доработки и компилятора и редактора связей именно из-за 16-ти разрядного OMF. Ведь в те времена у меня еще не было доступа в Интернет и к документации, поэтому я понятия не имел, что примерно в том же году Комитет по стандартам интерфейсов (TIS) принял спецификацию OMF версии 1.1, где узаконил использование этого формата и для 32-х разрядной среды.

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

Время шло, и у меня возникла необходимость следующего перехода. Теперь уже от 32-х разрядной среды Windows XP к 64-х разрядным Windows 7, 8, 10. И опять показалось, что вот тут-то и придется радикально переделать OMF или вообще отказаться от него, поскольку больше зарезервированных бит в нем не осталось, а тот самый TIS Committee (жив ли он?) не спешит выпускать новые версии спецификации. И вообще стали использоваться другие форматы вроде ELF-64 для Linux или Win64 у Microsoft.

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

В 64-х разрядной среде x86-64 для этого есть хорошие основания. Ведь в этой среде большинство процессорных инструкций чаще используют четырехбайтовую адрес-константу в своем коде, а не восьмибайтовую (хотя есть и такие команды). Дело в том, что на выполняемые программы наложено слабое ограничение: суммарный объем кодов и статических данных в образе EXE-файла не должен превышать 2 в 32 степени. В этом случае, так сказать, относительная (в пределах образа EXE-файла) адресация умещается в четыре байта, а, значит, и доработка OMF в этой части не потребуется. И это ограничение действительно слабое. Например, в программе, которая является основным видом моей деятельности, на сегодня коды занимают 2 мегабайта, статические данные – 11 мегабайт и, стало быть, я могу увеличивать ее еще в 330 раз, пока не выйду на это ограничение. При этом во время работы программа захватывает памяти уже полтора десятка Гбайт, но на использование OMF это никак не влияет.

Я пошел еще дальше, и наложил ограничение на загрузку своих программ: код не может загружаться по такому начальному адресу, чтобы образ EXE-файла выходил за 2 в 32 степени, т.е. как был адрес базы 400000H со времен Windows-XP, так он и остается. В конце концов, ведь адресация виртуальная и адресное пространство задачи изолировано. Ничто не мешает Windows загружать каждую программу именно в начало ее виртуального адресного пространства.

Данное ограничение позволяет не только использовать «внутри» образа EXE-файла четырехбайтовую адресацию, но и вообще использовать 32-х разрядные формы инструкций. Например, вместо:

можно использовать просто

т.е. без REX-префикса получить тот же эффект, поскольку процессор любезно автоматически обнулит старшую половину регистра RBX, что в данном случае и требуется. Получается, что только указатели на динамические объекты используют для адресации все восемь байт, а вся адресация статических переменных «внутри» EXE-файла остается 32-х разрядной и даже за счет исключения части REX-префиксов код становится более плотным. И такая адресация статических объектов представима в OMF.

Так можно ли использовать «древний» OMF для создания 64-х разрядных объектных модулей не переделывая капитально имеющиеся утилиты? Да, можно. Но одно исправление все-таки потребуется.

Дело в том, что для создания полностью перемещаемого кода в x86-64 введен режим адресации данных относительно текущего счетчика команд RIP. Если раньше такая адресация применялась только для команд переходов и вызовов, то теперь она стала применима и к данным.

Поясню на примере для тех, кто никогда не разбирался с режимами адресации. Пусть в 32-х разрядной среде имеется переменная X по адресу 408С90H, а по адресу 40120A имеется команда увеличения переменной на единицу:

В самом коде этой команды легко увидеть тот самый адрес 408С90H.

В 64-х разрядной форме этой же программы переменная X разместилась уже по адресу 40A5B8H, поскольку объем команд увеличился (главным образом, из-за REX-префиксов) и статические данные расположились по более далеким адресам. Но в команде:

уже не находится соответствующий адрес-константа 40A5B8, поскольку теперь адрес получается прибавление к RIP константы 93A8H, что и дает искомый адрес. 401210H+93A8H=40A5B8H

Дорабатывая OMF, сначала я хотел применить в таких случаях уже имевшуюся адресацию относительно RIP для команд переходов. Но выяснилось, что так не получится.

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

Объектный модуль в формате OMF состоит из множества отдельных частей-«записей», даже защищенных контрольными суммами. Типов записей много и они содержат разную информацию, но, пожалуй, главных две: одна имеет аббревиатуру LEDATA (Logical Enumerated Data Record), а другая аббревиатуру FIXUPP (Fixup Record).

Правда, я не вижу во второй аббревиатуре требуемой по смыслу буквы «R», вместо нее идет вторая «P», но, возможно, это не от слова «Record», а от слова «Previous», поскольку каждый FIXUPP относится к предыдущей LEDATA.

Так вот, когда достраиваются адреса переходов и вызовов, внутри очередного элемента записи FIXUPP указывается место адреса перехода от начала LEDATA и указание, каким должен получиться этот адрес. Редактор связей пересчитывает значение этого адреса в число относительно текущего счетчика команд RIP. Но когда процессор выполняет команду перехода, RIP уже показывает на начало следующей команды. Поэтому и относительный адрес перехода нужно рассчитывать не от начала данной команды, а от начала следующей. В случае инструкций CALL, JMP или условных переходов, следующая команда всегда начинается сразу после настраиваемого адреса, т.е. всегда через 4 байта (через байт для коротких условных) и редактор связей это учитывает.

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

Следующая команда начинается через байт после настраиваемого адреса:

Следующая команда начинается через 2 байта после настраиваемого адреса:

Поэтому-то уже имеющийся в FIXUPP способ адресации переходов относительно RIP и не подходит. Редактору связей еще нужно знать, где начинается следующая команда, чтобы правильно учесть значение RIP, а не только где в LEDATA расположен сам относительный адрес.

Поскольку я сопровождаю и компилятор, и редактор связей, и не требуется, к счастью, согласовывать изменения OMF с TIS Committee, я сделал доработку FIXUPP самым простым пришедшим в голову способом: приписал к началу каждого элемента записи FIXUPP еще по одному байту. Если этот байт нулевой – значит, относительная адресация данных в этой настройке не используется. Иначе он содержит число байт от начала настраиваемого адреса до конца данной процессорной инструкции.

Доработки редактора связей получились примитивными. Теперь он всегда читает еще один байт в каждом элементе записи FIXUPP. Если этот байт нулевой – никаких дополнительных действий не делается, иначе рассчитывается значение RIP с учетом числа в этом байте (оно не может быть меньше четырех) и из полученного значения RIP вычитается уже определенный ранее (в этом же элементе FIXUPP) «абсолютный» адрес самих данных. Вот пример фрагмента кода, где использованы три приведенные выше команды:

Вот этот же фрагмент в виде записи LEDATA:

А вот доработанный FIXUPP для настройки этой LEDATA:

Байты, содержащие 05, 06 и 07 как раз и содержат длины до конца инструкций в случае относительной адресации. Правда, по историческим причинам к этим длинам добавлена еще единица, но редактор связей это также учитывает.

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

Поскольку эти доработки очень простые, опять все заработало, что называется, с первого раза. И про OMF опять можно надолго забыть.

Заключение

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

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

Источник

В чем разница между форматом OMF и COFF?

недавно я поддерживал устаревший проект, написанный на VC++ 6.0. Код использует так много уникальных характеристик этого компилятора, что перенос его на более поздний стандартный компилятор оказался геркулесовой задачей.

среди тысяч строк кода в проекте есть четыре файла ассемблера. По какой-то причине я не понимаю, ни MASM615, ни TASM не могут их скомпилировать (они отправляют ошибки), тем не менее у меня есть объектные файлы. Однако, когда я связываю библиотека я получаю сообщение

предупреждение LNK4033: преобразование формата объекта из OMF в COFF

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

1 ответов

с рассвета цивилизации ПК до тех пор, пока не появились инструменты программирования Microsoft Win32, почти все компиляторы ПК производили объектные файлы, используя стандарт Intel Object Module Format (OMF). Позже Intel представила 386 процессоров и 32-битный защищенный режим, в котором они также расширили спецификацию OMF для 32-бит, что привело к «OMF-386», который стал стандартом для большинства ПК среды защищенного режима. Примерно в то же время оригинальная команда разработчиков Windows NT также разрабатывала код не только для процессоров Intel, но и для поддержки процессоров других поставщиков. Команда Microsoft NT выбрала более переносимый формат объектных модулей, известный как Common Object File Format (COFF), полученный из официального формата объектного кода для системы UNIX V. объектные модули COFF позже стали стандартом defacto для всех средств разработки Microsoft Win32 и получили преимущество в будучи намного ближе по формату к портативным исполняемым файлам-собственный исполняемый формат для Win32 (компоновщик формата COFF имеет гораздо меньше работы для создания 32-разрядного EXE или DLL из файла COFF, чем из файла формата OMF).

проблема со смешиванием объектных файлов и файлов библиотек от разных поставщиков компиляторов заключается в том, что некоторые поставщики поддерживают COFF, другие поставщики используют OMF, и некоторые могут обрабатывать оба. Например, Borland по-прежнему использует объектные файлы и библиотеки OMF, а 32-разрядные компиляторы Microsoft создают файлы формата COFF. Watcom C / C++ v11.0, похоже, предпочитает COFF при компиляции и связывании приложений Windows, но генерирует объектные файлы OMF для использования с их DOS4GW 32-разрядным DOS-расширителем защищенного режима. Наряду с этим, Microsoft MASM 6.13 по умолчанию создает файлы OMF, но с помощью переключателя /coff может испускать объектные файлы COFF вместо.

когда приходит время связывать файлы с разными форматами, разные компоновщики делают разные вещи. Например, компоновщик Microsoft Visual C / C++ предназначен для объектных файлов и библиотек формата COFF, но при необходимости попытается преобразовать объектные файлы OMF в файлы COFF. Это работает в некоторых случаях, но, к сожалению, Microsoft LINK не поддерживает все типы записей OMF, поэтому во многих ситуациях компоновщик может по-прежнему терпеть неудачу при задании объектных файлов формата OMF. Также в то время как Microsoft Ссылка пытается некоторую поддержку объектных файлов OMF, он откажется обрабатывать любые библиотеки формата OMF. Другие компоновщики, такие как Borland’s TLINK, предназначены для объектных файлов OMF и точно так же отказываются работать с объектными или библиотечными файлами формата COFF. Некоторые поставщики расширителей DOS и встроенных систем, такие как Phar Lap, предоставляют свои собственные компоновщики, которые поддерживают OMF и COFF, предоставляя вам выбор.

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

Источник

Расширение файла OMF

Оглавление

Мы надеемся, что вы найдете на этой странице полезный и ценный ресурс!

1 расширений и 1 псевдонимы, найденных в базе данных

✅ Routing J Server Routing Data

✅ Open Media Framework file

Другие типы файлов могут также использовать расширение файла .omf.

По данным Поиск на нашем сайте эти опечатки были наиболее распространенными в прошлом году:

Это возможно, что расширение имени файла указано неправильно?

Мы нашли следующие аналогичные расширений файлов в нашей базе данных:

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

Windows не удается открыть этот файл:

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

Если вы не знаете как настроить сопоставления файлов .omf, проверьте FAQ.

🔴 Можно ли изменить расширение файлов?

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

Если у вас есть полезная информация о расширение файла .omf, напишите нам!

Источник

Автоматическое управление пространством Oracle: место в сегментах, Undo, файлах OMF

Светлана Комарова

Автор статьи. Системный администратор, Oracle DBA. Информационные технологии, интернет, телеком. Подробнее.

Oracle Database 11g предлагает несколько средств автоматического управления пространством. Эти средства избавляют от необходимости выполнять вручную несколько традиционных рутинных задач. В этой заметке моего блога вы ознакомитесь со следующими средствами автоматического управления пространством:

Automatic Undo Management

Отмена (undo) обеспечивает возврат к образу данных в том виде, в каком они были на момент начала транзакции. Все параллельные транзакции, запущенные в базе данных, должны вмещаться в пространство отмены, выделенное для них, в противном случае транзакция даст сбой. Конкуренция за сегменты отката и управление пространством всегда были большой проблемой в управлении базой данных, но при использовании рекомендуемого Oracle режима Automatic Undo Management (AUM), об этих проблемах беспокоиться уже не нужно.

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

Oracle представил AUM в выпуске Oracle9i. Под управлением AUM сегменты отката создается внутренне, и называются сегментами отмены (undo segments). Oracle автоматически справляется с задачей выбора количества и размеров сегментов отката, параллельным доступом к блокам и обеспечением согласованности чтения. Когда вы создаете табличное пространство отмены при создании базы данных, Oracle создает набор сегментов отмены и автоматически увеличивает количество и размеры этих сегментов в соответствии с внутренним алгоритмом, в зависимости от загрузки базы данных.

Простое управление файлами с помощью OMF

OMF значительно упрощает обращение с файлами данных, управляющими файлами, файлами журналов повторного выполнения и файлами резервных копий RMAN. Обычно, если вы удаляете файл данных, база данных не имеет никаких ссылок на этот файл, но физический файл все еще остается на своем прежнем месте, и его потребуется удалить явно. При использовании OMF СУБД Oracle самостоятельно удалит файл, когда вы удалите его из базы данных. Согласно заявлению Oracle, файловые системы OMF больше всего подходят для баз данных, использующих Logical Volume Managers (диспетчеры логических томов), которые поддерживают RAID и расширяемые файловые системы. Больше всего от OMF выигрывают небольшие базы данных, потому что при этом сокращается объем работ по управлению файлами. Тестовые базы данных — еще одна область, где файловые системы OMF сокращают время управления.

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

Преимущества использования OMF

Можно создавать табличные пространства с файлами на базе OMF. Также можно указать, что файлы журналов повторного выполнения и управляющие файлы должны быть в формате OMF. Файлы OMF обеспечивают несколько преимуществ перед файлами, управляемыми пользователем.

В следующих разделах мы детально рассмотрим средства OMF.

Создание файлов OMF

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

Параметры инициализации для OMF

Чтобы разрешить использование файлов OMF, необходимо установить четыре параметра инициализации, которые можно оперативно изменять с помощью команды ALTER SYSTEM или ALTER SESSION. Эти параметры служат для указания местоположения различных типов файлов OMF.

Даже если не указать ни одного из этих параметров в файле init.ora или SPFILE, все равно с помощью команды ALTER SYSTEM можно динамически включить создание файлов OMF:

Пока специфицирован параметр DB_CREATE_FILE_DEST, можно рассчитывать на то, что Oracle будет создавать файлы OMF, и вы без проблем сможете пользоваться как управляемыми пользователем, так и файлами OMF.

Соглашения об именовании файлов

При построении имен файлов Oracle использует стандарт OFA, поэтому имена файлов уникальны и файлы данных легко идентифицируемы как относящиеся к определенному табличному пространству. В таблице 1 показаны соглашения об именовании различных видов файлов OMF с примерами для каждого типа. Обратите внимание, что буква t означает уникальное имя табличного пространства, g — группу онлайнового журнала повторного выполнения, а u — 8-символьную строку.

Пример

Типы файлов OMF

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

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

Как вы, вероятно, уже заметили, не существует специфического параметра, который должен быть включен в файл init.ora для указания формата OMF. Если вы специфицируете параметр CONTROL_FILES, то, конечно, должны указать полное местоположение управляющих файлов и, очевидно, они не будут файлами OMF — вы самостоятельно управляете ими. Если параметр CONTROL_FILES не задан, а используется параметр DB_CREATE_FILE_DEST или DB_CREATE_ONLINE_LOG_DEST_n, то управляющие файлы будут файлами OMF.

При использовании традиционного файла init.ora, в него понадобится добавить местоположение управляющих файлов. Если же применяется SPFILE, то Oracle добавит в него информацию об управляющих файлах автоматически.

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

Создание файлов журналов повторного выполнения OMF подобно созданию управляющих файлов. Если местоположение файлов журнала повторного выполнения не указано, но в файле init.ora установлен параметр DB_CREATE_FILE_DEST или DB_CREATE_ONLINE_LOG_DEST_n, то Oracle автоматически создаст файлы журналов повторного выполнения на основе OMF.

Файлы данных базы Oracle

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

Простое создание базы данных с использованием OMF

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

Установка параметров местоположения файлов

Давайте зададим для новой базы данных на базе OMF по имени NICKO следующие параметры инициализации:

Обратите внимание, что из четырех параметров инициализации, относящихся к OMF, выбраны только DB_CREATE_FILE_DEST, DB_RECOVERY_FILE_DEST_SIZE и DB_RECOVERY_FILE_DEST. В этом примере мне использовать четвертый параметр — DB_CREATE_ONLINE_LOG_DEST_n — не нужно. Когда этот параметр опущен, Oracle создает копию файла журнала повторного выполнения в месте, указанном параметрами DB_CREATE_FILE_DEST и DB_RECOVERY_FILE_DEST. Таким образом, есть две копии управляющего файла и онлайновых файлов журнала повторного выполнения.

Установка последнего параметра — LOG_ARCHIVE_DEST_1 — сообщает Oracle о том, что архивированные журналы повторного выполнения нужно отправлять в область пакетного восстановления, указанную в параметре DB_RECOVERY_FILE_DEST.

Запуск экземпляра

Используя простой файл init.ora из предыдущего раздела, можно запустить экземпляр, как показано в листинге ниже:

Создание базы данных

Теперь, после успешного создания экземпляра Oracle, можно создать новую базу данных NICKO с помощью следующей простой команды:

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

Не забудьте обновить файл параметров инициализации (initnicko.ora в рассмотренном примере) именами и местоположением копий управляющего файла, сгенерированными показанным здесь оператором CREATE DATABASE.

Где расположены файлы OMF

Увидеть различные файлы, относящиеся к базе данных, можно, заглянув в журнал предупреждений новой базы данных — alert_nicko.log, — который вы найдете в каталоги _$ORACLE_HOME/rdbms/log, поскольку мы не специфицировали в init.ora каталог BACKGROUND_DUMP_DEST. Если вы используете новый параметр Oracle Database 11g под названием DIAGNOSTIC_DEST, то найдете журнал предупреждений в каталоге /alert.

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

Вот что покажет журнал предупреждений относительно создания управляющих файлов:

Далее сервер Oracle создает файлы дублированных онлайновых журналов повторного выполнения. Oracle создает минимальное необходимое количество групп и дублирует их, создавая набор онлайновых файлов журналов (двух) в месте, заданном параметрами DB_CREATE_ONLINE_LOG_DEST и DB_RECOVERY_FILE_DEST:

Затем в месте, указанном в параметре DB_CREATE_FILE_DEST, создается табличное пространство System:

Далее, как показано ниже, создается табличное пространство по умолчанию Sysaux:

Затем в месте, указанном в параметре DB_CREATE_FILE_DEST, создается табличное пространство отмены с именем по умолчанию SYS_UNDOTS. Временное табличное пространство по имени TEMP также создается в этом каталоге.

Добавление табличных пространств

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

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

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

Онлайновое усечение сегментов и Segment Advisor

В Oracle рекомендуют применять онлайновое усечение сегментов ( online segment shrinking) для сжатия сегментов, которые со временем становятся фрагментированными из-за операций обновления и удаления. Маркер максимального уровня заполнения (high-water mark — HWM) сегмента показывает наивысшую точку использования пространства, достигнутую сегментом. Если имеется неиспользуемое пространство выше HWM, это значит, что такое пространство никогда не было использовано табличным или индексным сегментом.

В блогах уже упоминалось о том, что с помощью пакета DBMS_SPACE можно узнать объем неиспользуемого пространства в сегменте. Затем это неиспользуемое пространство сегмента можно отобрать, выдав оператор ALTER TABLE (или ALTER INDEX). DEALLOCATE. как показано ниже:

После выполнения этой команды Oracle возьмет все место свыше 1000 Мбайт из сегмента person и сделает его доступным для других сегментов в табличном пространстве.

Например, если при вставке строк вы использовали 80% пространства табличного сегмента, то HWM для этого сегмента составит 80%. Позднее, даже если половина строк будет удалена, HWM таблицы останется на уровне 80%. Это дает нежелательный эффект при полнотабличном сканировании, а также сканировании индексов, потому что Oracle будет постоянно сканировать таблицу вплоть до HWM, даже несмотря на то, что в данный момент в таблице находится очень мало данных.

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

Начиная с версии Oracle Database 10g, можно использовать возможность усечения сегментов, чтобы отобрать свободное пространство у разреженных сегментов и вернуть его родительскому табличному пространству. Можно понизить HWM, сделав данные в сегменте более компактными. Кроме того, начиная с Oracle Database 10g, можно усекать таблицы (включая индекс-таблицы), разделы и подразделы таблиц, индексов и материализованных представлений (а также журналы материализованных представлений).

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

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

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

Ручное усечение сегментов

Для усечения сегментов применяются простые команды SQL. Операции усечения сегментов сжимают фрагментированное пространство в сегментах и дополнительно освобождают пространство.

Перед усечением сегментов сначала для каждого такого сегмента необходимо разрешить перемещение строк. Это делается с помощью конструкции ENABLE ROW MOVEMENT в команде ALTER TABLE, как показано ниже:

Разумеется, если конструкция ENABLE ROW MOVEMENT была специфицирована еще во время создания таблицы, запускать эту команду перед операцией усечения сегментов не придется. По умолчанию перемещение строк на уровне сегмента отключено. Операция усечения сегментов включает в себя две фазы.

Внимание! Во время фазы сжатия объект остается в онлайновом режиме и доступен, но во время второй фазы объект становится кратковременно недоступным — из-за исключительной блокировки сегмента.

Базовый оператор усечения сегментов выполнят обе фазы этой операции последовательно (сначала собственно сжимая данные, а затем переустанавливая HWM и возвращая высвобожденное пространство). Ниже приведен пример этого оператора (имя сжимаемой таблицы — test):

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

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

Таким образом, в часы пиковых нагрузок база данных просто упакует пространство в сегменте. Затем, в часы минимальных нагрузок, можно будет запустить команду ALTER TABLE имя_таблицы SHRINK SPACE, которая завершит процесс усечения, выполнив вторую его фазу.

В случае указания опции CASCADE в операции усечения сегмента все зависимые сегменты также будут усечены. Например, при усечении таблицы все зависимые индексные сегменты также будут автоматически усечены. Ниже показан пример применения опции CASCADE:

Использование Segment Advisor для усечения сегментов

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

На заметку! Использовать Segment Advisor можно только в Oracle Database 10.1 и 10.2, а также в Oracle Database 11g Release 1 и последующих выпусках (12c в том числе). Для запуска Segment Advisor понадобится привилегия ADVISOR (в дополнение к привилегии CREATE ANY JOB (или CREATE JOB)).

Выбор объектов — кандидатов на усечение

Вызывать Segment Advisor можно либо на уровне индивидуального сегмента, либо на уровне табличного пространства. Запустить Segment Advisor можно со страницы Advisor Central (Центр советников) в интерфейсе Database Control (куда можно добраться из домашней страницы Database Control щелчком на ссылке Advisor Central в разделе Related Links (Связанные ссылки), а затем щелкнув на ссылке Segment Advisor (Советник по сегментам)). На рисунке ниже показана главная страница Segment Advisor.

Segment Advisor может генерировать рекомендации на трех уровнях: объекта, сегмента и табличного пространства. Рекомендация может состоять в усечении или реорганизации, в зависимости от перечисленных ниже критериев.

Запускать Segment Advisor можно в двух режимах.

AWR собирает всю статистику по использованию пространства во время регулярного сбора снимков. Segment Advisor для оценки будущих потребностей сегмента в пространстве применяет отчет о тенденциях роста, основанный на данных использования пространства AWR. Просмотреть рекомендации Segment Advisor можно через OEM, щелкнув на ссылке Segment Advisor Recommendations (Рекомендации советника по сегментам) на странице Segment Advisor.

Автоматическое задание Segment Advisor

В Oracle Database 10.2 и последующих версиях Oracle предоставляет автоматическое задание Segment Advisor по имени AUTO_SPACE_ADVISOR_JOB, которое автоматически определяет проблемы, связанные с пространством сегмента. Вот детали задания, которые можно увидеть через представление DBA_SCHEDULER_JOBS:

Задание Segment Advisor запускается автоматически во время окна обслуживания, идентифицируя кандидатов на операцию усечения сегментов в зависимости от степени фрагментации пространства внутри объекта. Просматривать рекомендации задания Segment Advisor можно точно так же, как рекомендации советника Segment Advisor, вызванного вручную, как было показано в предыдущем разделе. Если щелкнуть на ссылке Segment Advisor Recommendations на странице Segment Advisor, отобразится список рекомендаций Segment Advisor, подготовленных им при последнем запуске. Страница Segment Advisor Recommendations показана на рисунке ниже:

Автоматическая настройка контрольных точек

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

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

На заметку! Время, необходимое на выполнение второй фазы (откат), зависит от того, насколько много информации отмены нужно откатить.

Начиная с версии Oracle Database 10g, можно автоматизировать настройку контрольных точек, полностью избегая установки любых параметров инициализации, относящихся к контрольным точкам, присвоив параметру FAST_START_MTTR_TARGET ненулевое значение. По умолчанию значение этого параметра равно 0. Oracle автоматически настроит формирование контрольных точек, находя компромисс между потребностями восстановления и накладными расходами пропускной способности базы данных.

Источник