Oracle online: возможности по реорганизации таблиц, индексов и переопределению данных

Возможности базы данных oracle online переносить и реорганизовывать таблицы, индексы, блоки данныхВ дополнение к средствам автоматического управления базой данных Oracle Database 11g и 12c предлагает возможности выполнения многих распространенных задач к онлайновом режиме, сокращая объем работы, которую пришлось бы выполнить только после останова базы данных или перевода объекта в отключенное состояние. В некоторых случаях (как при использовании команды MOVE) операции DML приостанавливаются до тех пор, пока таблица не будет перемещена. Эти средства обеспечивают непрерывную доступность базы, облегчая решение задач реорганизации. В этой статье блога мы рассмотрим некоторые важнейшие онлайновые возможности Oracle Database 11g и 12c.

 

Онлайновая реорганизация данных

Oracle и ранее предлагал несколько онлайновых средств реорганизации, таких как возможность создания разделов, перемещения таблиц и добавления ограничений. Но Oracle Database 11g идет намного дальше и предлагает больше онлайновых возможностей для администратора баз данных, включая онлайновую реорганизацию базы данных, проверку достоверности объектов и перестройку индексов.

 

Онлайновая реорганизация базы данных с помощью OEM Database Control

С использованием интерфейса OEM Database Control можно легко выполнять отключенную или онлайновую реорганизацию объектов базы данных. Часто возникает потребность в изменениях атрибутов хранения таблицы или индекса, и Database Control значительно облегчит выполнение таких реорганизаций.

Чтобы выполнить реорганизацию базы данных с помощью Database Control, обратитесь к домашней странице Database Control и выберите там AdministrationReorganize Objects (Администрирование > Реорганизовать объекты). На рисунке ниже показана главная страница средства реорганизации данных в Database Control. Здесь можно выбирать между отключенной и онлайновой реорганизацией.

После выбора метода онлайновой реорганизации OEM запросит список объектов, которые должны быть реорганизованы. Затем он сгенерирует отчет о влиянии и итоговое задание, которое представляет собой результат действительного сценария реорганизации. На следующем шаге вы решаете, выполнять ли онлайновую реорганизацию немедленно или запланировать ее на более позднее время.

 

Использование команд SQL для выполнения онлайновой реорганизации данных

В дополнение к средству онлайновой реорганизации данных, которое кратко описано в разделе “Онлайновое переопределение данных” ниже в этой статье блога, можно реорганизовать данные в таблицах и индексах в онлайновом режиме, используя для этого различные команды SQL. Давайте вкратце рассмотрим важнейшие методы реорганизации данных, начиная с команды проверки достоверности объекта.

 

Онлайновая проверка достоверности объекта

Пока пользователи вносят изменения в таблицу, можно проверить структуру объекта, применив для этого оператор ANALYZE TABLE...VALIDATE STRUCTURE, например: 

SQL> ANALYZE TABLE persons
2 VALIDATE STRUCTURE ONLINE;
Table analyzed.
SQL>

 

Перестройка индекса в онлайновом режиме

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

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

Вот пример онлайновой перестройки индекса:

SQL> ALTER INDEX test_idx REBUILD ONLINE;

 

Создание индекса в онлайновом режиме

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

SQL> CREATE INDEX test_idx ON persons(person_id) ONLINE; 

 

Перераспределение индекса в онлайновом режиме

Перераспределение (coalesce) индекса в онлайновом режиме выполняется таким оператором:

SQL> ALTER INDEX test_idx COALESCE; 

Перемещение таблицы в онлайновом режиме

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

SQL> ALTER TABLE test MOVE TABLESPACE new_tbsp 

 

Онлайновое переопределение данных

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

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

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


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


 

Что позволяет сделать онлайновое переопределение

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

  • Добавление, удаление и переименование столбцов.
  • Преобразование данных таблиц.
  • Изменение типов данных столбцов.
  • Переименование ограничений таблиц.
  • Изменение исходных параметров хранения.
  • Сокращение фрагментации таблиц.
  • Создание секционированных таблиц из обычных таблиц в онлайновом режиме.
  • Создание индекс-таблиц (IOT) из обычных таблиц.
  • Перемещение таблиц в другие табличные пространства.

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

Онлайновое переопределение таблицы предусматривает выполнение следующей простой последовательности шагов.

  1. Определить таблицу — кандидата на переопределение.
  2. Принять решение о структуре новой таблицы и создать новый образ таблицы.
  3. Начать процесс переопределения, используя пакет DBMS_REDEFENITION.
  4. Создать необходимые ограничения и триггеры на новой таблице.
  5. Выполнять периодическую синхронизацию и проверку достоверности данных новой таблицы.
  6. Завершить переопределение таблицы.

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

 

Пример онлайнового переопределения таблицы

В этом примере мы реорганизуем таблицу employees в схеме HR, которая имеет структуру, показанную ниже. Для этого примера цель состоит в удалении столбца salary из таблицы employees


Name              Null?              Type
---------------   --------   ------------
EMPLOYEE_ID       NOT NULL      NUMBER(6)
FIRST_NAME                   VARCHAR2(20)
LAST_NAME         NOT NULL   VARCHAR2(25)
EMAIL             NOT NULL   VARCHAR2(25)
PHONE_NUMBER                 VARCHAR2(20)
HIRE_DATE         NOT NULL           DATE
JOB_ID            NOT NULL   VARCHAR2(10)
SALARY                        NUMBER(8,2)
COMMISSION_PCT                NUMBER(2,2)
MANAGER_ID                      NUMBER(6)
DEPARTMENT_ID                   NUMBER(4)

Наша цель — исключить столбец salary из таблицы employees и секционировать таблицу, используя схему диапазонов на основе столбца employee_id. После завершения онлайнового переопределения временную таблицу можно удалить. Новая таблица будет иметь все атрибуты временной таблицы.

 

Проверка пригодности таблицы

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

SQL> BEGIN
2 DBMS_REDEFINITION.CAN_REDEF_TABLE('hr','employees');
3 END;
4 /
PL/SQL procedure successfully completed.
SQL>

В третьем параметре процедуры DBMS_REDEFINITION.CAN_REDEF_TABLE можно указать метод онлайнового переопределения в дополнение к именам владельца схемы (hr) и таблицы (employees). Третий параметр называется options_flag и может принимать два возможных значения: DBMS_REDEFINITION.CONS_USE_PK для метода первичного ключа или DBMS_REDEFINITION.CONS_USE_ROWID для метода ROWID. Поскольку используется метод первичного ключа, третий параметр специфицировать не понадобится.


На заметку! Для выполнения онлайнового переопределения таблица в первичном ключе не нуждается.


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

 

Создание временной таблицы

При переопределении рабочей таблицы изменять ее напрямую не следует. Намного безопаснее иметь возможность предварительно проверить переопределение и увидеть результат. Затем существующую рабочую таблицу можно заменить промежуточной таблицей. В рассматриваемом примере промежуточная таблица hr.employees_temp не будет иметь столбца salary. Она также будет секционирована по значению столбца employee_id, как показано в листинге 1. Эти два изменения — удаление столбца salary и секционирование таблицы — являются целью упражнения по переопределению таблицы. 


SQL> CREATE TABLE hr.employees_temp
2 (employee_id number(6),
3 first_name varchar2(20) not null,
4 last_name varchar2(25) not null,
5 email varchar2(25) not null,
6 phone_number varchar2(20),
7 hire_date date not null,
8 job_id varchar2(10) not null,
9 commission_pct number(2,2),
10 manager_id number(6),
11 department_id number(4))
12 PARTITION BY RANGE(employee_id)
13 (PARTITION employees1
VALUES LESS THAN (100) tablespace TEST01,
14* PARTITION employees2
VALUES LESS THAN (300) tablespace TEST02);
Table created.
SQL>

 

Переопределение таблицы

Теперь можно приступить к процессу переопределения, используя процедуру DBMS_REDEFINITION.START_REDIF_TABLE, как показано в листинге 2. Процедура START_REDIF_TABLE принимает следующие параметры.

  • UNAME — имя схемы (hr).
  • ORIG_TABLE — таблица, подлежащая переопределению (employees).
  • INT_TABLE — имя промежуточной таблицы.
  • COL_MAPPING — указывает отображение столбцов промежуточной таблицы на столбцы исходной таблицы. Если значения этого параметра не заданы, то все столбцы исходной таблицы будут включены в промежуточную таблицу.
  • OPTIONS_FLAG — специфицирует метод переопределения. Поскольку в рассматриваемом примере используется метод первичного ключа, этот параметр можно опустить.

Совет. Для переопределения таблицы необходимо быть зарегистрированным в качестве владельца схемы. Удостоверьтесь, что владельцу схему выданы привилегии для доступа к пакету DBMS_REDEFINITION. Владелец схемы также должен иметь право на выбор, создание, изменение, уничтожение и блокирование любой таблицы. В противном случае вы получите ошибку ORA-01031 “Insufficient privileges” (недостаточные привилегии).



SQL> BEGIN
2 dbms_redefinition.start_redef_table('hr','employees',
3 'employees_temp',
4 'employee_id employee_id,
5 first_name first_name,
6 last_name last_name,
7 email email,
8 phone_number phone_number,
9 hire_date hire_date,
10 job_id job_id,
11 commission_pct commission_pct,
12 manager_id manager_id,
13 department_id department_id');
14 END;
15 /
PL/SQL procedure successfully completed.
SQL> 

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

SQL> SELECT COUNT(*) FROM employees_temp;
COUNT(*)
-----------
107
SQL> SELECT COUNT(*) FROM employees;
COUNT(*)
----------
107
SQL> 

 

Копирование зависимых объектов

Далее потребуется запустить процедуру DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS, чтобы автоматически создать все существующие триггеры, индексы, привилегии и ограничения для таблицы HR.EMPLOYEES_TEMP. Вот как это делается: 

SQL> DECLARE
SQL> num_errors PLS_INTEGER;
SQL> BEGIN
DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS('hr', 'employees', 'employees_temp',
DBMS_REDEFINITION.CONS_ORIG_PARAMS, TRUE, TRUE, TRUE, TRUE, num_errors);
END;

Совет. Запустив задание переопределения в параллельном режиме, можно повысить производительность процесса переопределения. Для этого сначала нужно выполнить следующие операторы, после чего запустить процедуру START_REDEF_TABLE для выполнения процесса переопределения:

SQL> alter session force parallel dml parallel 8;
SQL> alter session force parallel query parallel 8; 

СУБД Oracle позволяет онлайн реорганизовывать таблицы и индексы,изменять размер блока и замораживать базу

 

Что происходит во время процесса переопределения

Использовать пакет DBMS_REDEFINITION легко, но при этом “за кулисами” происходит очень многое. При выполнении процедуры DBMS_REDEFINITION.START_REDEF_TABLE создаются две новых таблицы: временная и постоянная. Временная таблица называется RUPD$_Employee, и она существует на протяжении сеанса. Постоянная таблица — это снимок, содержащий все изменения, проведенные в главной таблице employees во время выполнения процедуры START_REDEF_TABLE. Строки главной таблицы копируются в промежуточную таблицу, и пользователи смогут обновлять главную таблицы во время этого процесса. Изменения, проведенные пользователями, во время этого процесса заносятся в материализованный журнал.

В листинге 3 приведен запрос к DBA_OBJECTS, который показывает, что новая таблица секционирована на основе заданного переопределения. Запрос также показывает две новых таблицы, созданные во время процесса онлайнового переопределения. 


SQL> SELECT object_type, object_name
2 FROM dba_objects
3 WHERE object_name LIKE '%EMPLOYEES%';
OBJECT_TYPE             OBJECT_NAME
----------------   ----------------
TABLE                     EMPLOYEES
TABLE PARTITION      EMPLOYEES_TEMP
TABLE PARTITION      EMPLOYEES_TEMP
TABLE                EMPLOYEES_TEMP
TABLE                 EMPLOYEES_NEW
SEQUENCE              EMPLOYEES_SEQ
TABLE               MLOG$_EMPLOYEES
TABLE               RUPD$_EMPLOYEES
TRIGGER            SECURE_EMPLOYEES
9 rows selected.
SQL>

 

Проверка ошибок

С помощью представления DBA_REDEFINITION_ERRORS можно проверить, не возникали ли ошибки во время процесса переопределения:

SQL> SELECT OBJECT_NAME, BASE_TABLE_NAME, DDL_TXT
FROM DBA_REDEFINITION_ERRORS; 

 

Синхронизация промежуточной и исходной таблиц

Процедура SYNC_INTERIM_TABLE служит для синхронизации данных в промежуточной и исходной таблицах. Это не обязательный шаг. Вот как выполняется эта процедура:

SQL> EXECUTE dbms_redefinition.sync_interim_table ('hr', -
> 'employees','employees_temp');
PL/SQL procedure successfully completed.
SQL>

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

 

Завершение процесса переопределения

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

В рассматриваемом примере таблица employees пока еще не секционирована и содержит столбец salary.

SQL> EXECUTE DBMS_REDEFINITION.FINISH_REDEF_TABLE ('hr', -
> 'employees', 'employees_temp');
PL/SQL procedure successfully completed.
SQL>

При запуске процедуры FINISH_REDEF_TABLE происходит следующее.

  • Oracle читает материализованный журнал главной таблицы, чтобы добавить его содержимое к промежуточной таблице.
  • Таблица employees переопределяется таким образом, что получает все атрибуты, индексы, ограничения и права промежуточной таблицы — employees_temp.
  • Включаются все ссылочные ограничения, включающие таблицу employees_temp.
  • Любые триггеры, которые вы определили на таблице employees_temp, также появляются на вновь переопределенной таблице и становятся действующими.
  • Две таблицы на короткое время блокируются в исключительном режиме для проведения необходимых изменений в словаре данных.
  • Материализованное представление и журнал уничтожаются.

Запустив следующий запрос, можно убедиться, что исходная таблица employees теперь действительно секционирована:

SQL> SELECT object_type, object_name
2 FROM dba_objects
3* WHERE object_name ='EMPLOYEES';
OBJECT_TYPE     OBJECT_NAME
--------------- -----------
TABLE PARTITION   EMPLOYEES
TABLE PARTITION   EMPLOYEES
TABLE             EMPLOYEES
SQL>

Если посмотреть на структуру таблицы employees (скажем, с помощью команды DESCRIBE), легко заметить, что она уже не содержит столбца salary.

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

Если вы увидите какие-либо существенные ошибки во время описанного процесса, переопределение легко прервать, используя процедуру DBMS_REDEFINITION.ABORT_REDEF_TABLE. Эта процедура уничтожает временную таблицу и журналы, созданные во время процесса переопределения. Затем можно вручную удалить промежуточную таблицу.

 

Динамическое управление ресурсами

Традиционно, как только любой пользователь запускает транзакцию в базе данных, ему выдается тот же приоритет, что и другим сеансам базы данных. Иногда это может привести к тому, что единственный пользователь монополизирует ресурсы базы данных, замедлив ее работу. В наших блогах я уже встречал информацию о том, как диспетчер ресурсов базы данных (Database Resource Manager) может помочь в управлении ресурсами базы данных за счет использования групп и планов ресурсов для выделения критичных ресурсов.

В дополнение к возможностям выделения ресурсов Database Resource Manager включает следующие средства, помогающие в онлайновом управлении транзакциями.

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

В следующих разделах будет описано, как выполнить каждую из этих задач посредством Database Resource Manager.

 

Переключение длительно выполняющихся транзакций

Database Resource Manager позволяет применять директивы планирования (plan directives), которые могут наложить ограничения на использование ресурсов. Директивы планирования включают следующие параметры, которые служат для сдвига приоритетов групп потребителей:

  • SWITCH_TIME
  • SWITCH_GROUP
  • SWITCH_ESTIMATE
  • SWITCH_IO_MEGABYTES
  • SWITCH_IO_REGS
  • SWITCH_FOR_CALL

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

Установка параметра SWITCH_ESTIMATE в true предоставляет диспетчеру Database Resource Manager определять, нужно ли переключать пользовательский сеанс еще перед запуском операции. В этом случае Database Resource Manager оценивает время, которое потребуется для завершения операции, и на основе этой оценки определяет, следует ли ему сразу переключить группу потребителей ресурсов пользователя.

Атрибут SWITCH_IO_MEGABYTES в директиве планирования ресурсов позволяет специфицировать объем ввода-вывода (Мбайт), который может произвести сеанс перед тем, как база данных предпримет какие-то действия — вроде переключения сеанса в другую группу ресурсов или прерывания его. Параметр SWITCH_IO_REQS позволяет специфицировать количество запросов ввода-вывода, которые может выдать сеанс перед тем, как база данных ограничит для него использование операций ввода-вывода. Установка параметра SWITCH_FOR_CALL в true заставляет базу данных вернуть переключенный сеанс в его исходную группу после завершения вызова верхнего уровня (top call).

 

Ограничение количества длительных транзакций с помощью очередности операций

При создании группы потребителей ресурсов с использованием Database Resource Manager можно установить пул активных сеансов для каждой группы. Активный сеанс — это такой сеанс, в котором в данный момент активна транзакция или операция выборки данных. Как только достигается лимит пула группы активных сеансов, новые сеансы, принадлежащие к той же группе, активизироваться не могут. Database Resource Manager выстраивает их в очередь и активизирует только после завершения текущих активных сеансов.

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

 

Ограничение максимального времени выполнения транзакции

Все администраторы баз данных опасаются возможности, что кто-то запустит громадное задание, которое поглотит большую часть ресурсов базы данных и буквально поставит ее на колени. В большинстве случаев вам придется решать, можно ли уничтожить такую долго выполняющуюся задачу. Диспетчер Database Resource Manager дает возможность избежать стрессовых ситуаций подобного рода, позволяя установить лимит времени выполнения операций — т.е. он позволит запускать только те задания, которые укладываются в максимальный лимит времени выполнения, установленный вами.

Существуют два способа ограничить время выполнения транзакции в базе данных: директивы планирования ресурсов MAX_ESTIMATED_EXEC_TIME и UNDO_POOL.


На заметку! Для отслеживания длительно выполняющихся операций можно использовать процедуру DBMS_APPLICATION.SET_SESSION_LONGOPS. Эта процедура наполняет представление V$SESSION_LONGOPS.


 

Использование директивы планирования ресурсов MAX_ESTIMATED_EXEC_TIME

Ограничить максимальное время выполнения транзакций можно с помощью директивы планирования ресурсов MAX_ESTIMATED_EXEC_TIME. Если этот параметр установлен, Database Resource Manager оценит время выполнения операции и прервет ее, если время ее выполнения превысит максимальное ожидаемое значение, установленное вами.

 

Использование директивы планирования ресурсов UNDO_POOL

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

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

 

Онлайновое изменение размера блока базы данных

Предположим, что есть табличное пространство, имеющее размер блока в 8 Кбайт, как показано в следующем примере:

SQL> SELECT NAME, VALUE FROM V$SPPARAMETER
2 WHERE NAME='db_block_size';
NAME            VALUE
--------------  -----
db_block_size   8192
SQL> 

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

В листинге 4, который показывает результаты запроса в моей тестовой базе данных, вы не увидите никаких значений под каждым из пяти возможных параметров DB_nK_CACHE_SIZE. Это потому, что был выбран только один размер блока — стандартный размер в 8 Кбайт, и никаких других дополнительных размеров кэша. Общее значение DB_CACHE_SIZE показано в листинге как 25 Мбайт (25 165 824 байт), и все оно состоит из стандартных блоков по 8 Кбайт. 


SQL> SELECT NAME, VALUE FROM V$PARAMETER
2 WHERE NAME LIKE '%cache_size%';
NAME                         VALUE
----------------------  ----------
db_keep_cache_size               0
db_recycle_cache_size            0
db_2k_cache_size                 0
db_4k_cache_size                 0
db_8k_cache_size                 0
db_16k_cache_size                0
db_32k_cache_size                0
db_cache_size             25165824
8 rows selected.
SQL>

Несложно создать в онлайновом режиме новый размер буферного кэша в 16 Кбайт и создать новое табличное пространство с этим размером блока. Затем можно создавать нужные объекты в этом новом табличном пространстве или же переместить в это пространство любые существующие объекты — и все это тоже в онлайновом режиме.

Ниже описано, что потребуется сделать. Для начала создайте новый буферный кэш 16 Кбайт, чтобы можно было создать табличное пространство с размером блока в 16 Кбайт: 

SQL> ALTER SYSTEM SET DB_16K_CACHE_SIZE =1024M;
System altered.
SQL>

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

SQL> CREATE TABLESPACE big_block
3 DATAFILE '/test01/app/oracle/big_block_01.dbf' SIZE 1000M
4* BLOCKSIZE 16K;
Tablespace created.
SQL>

При наличии таблицы, которую нужно перенести в табличное пространство big_block с размером блока в 16 Кбайт, все, что понадобится — это следующая команда MOVE:

SQL> ALTER TABLE test MOVE TABLESPACE big_block;
Table altered.
SQL>

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

 

Использование замораживания базы данных для онлайнового обслуживания

Предположим, что необходимо изменить схему таблицы. Если есть транзакция, использующая таблицу в данный момент, вы не сможете выполнить эту задачу. Если процедура PL/SQL будет позднее обновлена, чтобы отразить изменение в схеме, то пользователи, пытающиеся в данный момент выполнить эту процедуру, получат ошибку. К счастью, Oracle имеет замечательное средство замораживания (quiescing), благодаря которому не придется останавливать базу данных и открывать ее в ограниченном режиме.

Это средство используется, когда нужно выполнить действие, которое требует, чтобы в базе данных не было активных транзакций. Пока база находится в замороженном состоянии, пользователи остаются подключенными и могут продолжать выполнять свои запросы, которые находятся в процессе обработки. Однако база данных будет блокировать все новые запросы транзакций, за исключением тех, что поступают от SYS или SYSTEM. Поскольку текущим выполняющимся запросам будет позволено завершиться, база данных при этом остается в большей степени доступной, чем в ограниченном (restricted) режиме. То есть замораживание переводит базу данных в режим частичной доступности. Когда она выйдет из этого режима, любые запросы пользователей, которые были блокированы, автоматически продолжат обрабатываться.

Следующие команды выполняют замораживание и размораживание базы данных

SQL> ALTER SYSTEM QUIESCE RESTRICTED;
SQL> ALTER SYSTEM UNQUIESCE;

На заметку! Не каждый пользователь с привилегиями администратора баз данных может заморозить базу данных. Это средство доступно только пользователям SYS и SYSTEM.


Пользователи могут продолжать входить в системе, если только не используется архитектура с разделяемым (shared) сервером. Типичные операции обслуживания, которые могут потребовать применения средства замораживания базы данных — это те, которым нужен исключительный доступ к объекту, наподобие ALTER TABLE, DROP TABLE или CREATE PROCEDURE. Любой оператор DDL, который может пожелать выполнить администратор баз данных в живой базе, потребует исключительных блокировок, и ни один из них не пройдет, если существуют активные транзакции, использующие таблицу.

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

 

Приостановка базы данных

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

SQL> ALTER SYSTEM SUSPEND;
System altered.
SQL> ALTER SYSTEM RESUME;
System altered.

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

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

 

Вас заинтересует / Intresting for you:

Oracle alerts: генерируемые се...
Oracle alerts: генерируемые се... 7216 просмотров Алексей Вятский Tue, 21 Nov 2017, 13:18:05
Oracle Personal Edition
Oracle Personal Edition 5963 просмотров Надин Tue, 21 Nov 2017, 13:32:12
Установка Oracle 11g на Linux
Установка Oracle 11g на Linux 22899 просмотров Илья Дергунов Tue, 21 Nov 2017, 13:18:05
Создание таблиц  в базе данных...
Создание таблиц в базе данных... 16372 просмотров Administrator SU Mon, 28 Oct 2019, 08:20:14
Войдите чтобы комментировать