Я тоже писал об этом раньшеORACLEСтатья о новых функциях 11G, сейчасORACLE11G стала мейнстримомORACLEВерсия базы данных, понимание и изучениеORACLEНовые функции 11G крайне важны, и я тоже.ORACLEДля новичков в новых функциях 11G я хотел бы поделиться здесь своим процессом обучения и опытом.
В этой статье главным образом отмечается:ORACLEНовая функция 11g, позволяющая замкам DDL ждать блокировки DML, что также является темой, которую разделил господин Чжан Лей (камус) на мероприятии ACOUG 30 июня.
В версиях до 11g по умолчанию DDL-блокировки не ждут DML-блокировок, и если выполнить операции DDL над таблицей с DML-блокировками, сразу же возникнет сбой (кроме той же СЕССИИ). Давайте проведём простой эксперимент: вставим данные в таблицу STREAM в SESSION1, не отправляй, в этот момент у таблицы STREAM будет блокировка DML, и выполним операцию TRUNCATE таблицы STREAM в SESSION2, и немедленно появится ошибка:
SESSION1 >вставьте в режим выбора потока * из DBDREAM; Создано 10 строк. SESSION2 >усечь поток стола; Поток усеченной таблицы * ОШИБКА в строке 1: ORA-00054: ресурс занят и приобретение с указанием NOWAIT или тайм-аут истекшим в версии 11g,ORACLEВведён DDL_LOCK_TIMEOUT параметр, позволяющий блокировкам DDL ждать блокировки DML, которые управляют временем ожидания блокировок DML, за секунды по умолчанию равен 0, то есть блокировки DDL не ждут блокировок DML, максимальное значение составляет 1 миллион, то есть 11,5 дней, этот параметр можно задать глобально или на уровне SESSION.
SESSION2 >показать параметр ddl_lock_timeout ЗНАЧЕНИЕ ТИПА ИМЕНИ ----------------------- ----------- ------ ddl_lock_timeout ЦЕЛОЕ ЧИСЛО 0 SESSION2 >alter session set ddl_lock_timeout=2000000; ОШИБКА: ORA-00068: недопустимое значение 2000000 для параметра ddl_lock_timeout, должно быть от 0 до 1000000. Ниже демонстрируется эффект следующего параметра DDL_LOCK_TIMEOUT, а также приведена вышеуказанная таблица STREAM в качестве примера, текущая таблица STREAM всё ещё имеет блокировку DML, в SESSION2 будет DDL_LOCK_ TIMEOUT устанавливается на 60 секунд, после чего выполняется операция TRUNCATE, и сбой не возвращается сразу, а будет ждать 60 секунд, и если блокировка DL таблицы STREAM не будет освобождена в течение 60 секунд, результат сбоя возвращается.
SESSION2 >alter session set ddl_lock_timeout=60; Сессия изменена. SESSION2 >установите тайминг на SESSION2 >усекайте поток стола; --На этом этапе SESSION2 приостанавливается, ждёт, пока SESSION1 снимет блокировку DML в течение 60 секунд, возврат неудачен через 60 секунд усечение потока таблицы * ОШИБКА на строке 1: ORA-00054: ресурс занят и получение с указанием NOWAIT или истечённым тайм-аут Прошло: 00:01:00.01 Появление DDL_LOCK_TIMEOUT параметров значительно упрощает работу DBA, например, мы хотим добавить поле в таблицу, но в этой таблице много операций DML, и мы не можем использовать метод ALTER SYSTEM KILL SESSION для завершения этих операций, поэтому, если мы хотим добавить поля в эту таблицу, нужно бесчисленное количество раз выполнять операцию добавления полей или писать скрипты для этой задачи, и теперь у нас есть DDL_ LOCK_TIMEOUT параметре нужно лишь немного увеличить значение этого параметра, и не нужно беспокоиться о выполнении SQL, давайте продемонстрируем этот процесс ниже.
SESSION2 добавить поля:
SESSION2 >alter table stream add jpg_path varchar2(255) по умолчанию '/home/Оракул/'; 此时挂起，等待STREAM表的DML锁释放，SESSION1提交释放DML锁后，SESSION2操作便成功了。
SESSION1 >Commit; Коммит выполнен. SESSION2 >alter table stream add jpg_path varchar2(255) по умолчанию '/home/Оракул/'; Table altered. SESSION2 >select * from stream; ID IDENTIFIER PIC_NO JPG_PATH ---------- --------------- ------ --------------- 1 18-0220-003 1 /home/Оракул/ 2 18-0221-003 1 /home/Оракул/ 3 18-0221-003 2 /home/Оракул/ 4 18-0221-003 3 /home/Оракул/ 5 18-0223-005 1 /home/Оракул/ 6 18-0223-005 2 /home/Оракул/ 7 18-0223-005 3 /home/Оракул/ 8 18-0223-005 4 /home/Оракул/ 9 18-0223-005 5 /home/Оракул/ 10 18-0223-005 6 /home/Оракул/ 10 rows selected.
|
Опубликовано 26.11.2014 15:54:15
|
|
|
