Метод выключения Oracle


9

Завершение работы базы данных перед обновлением или исправлением можно выполнить несколькими способами.

shutdown immediate;

или

shutdown abort;
startup restrict;
shutdown immediate;

или

shutdown abort;
startup restrict;
shutdown;

или

alter system checkpoint;
shutdown abort;
startup restrict;
shutdown immediate;

Конечно, есть и другие варианты. Что должно быть предпочтительным и почему?

Ответы:


12

Цель при закрытии для обслуживания (или холодного резервного копирования) состоит в том, чтобы база данных оставалась в согласованном состоянии без необходимости отката / восстановления при запуске.

Есть 3 команды SQL * Plus, shutdownкоторые достигают этого в теории, и все они немедленно предотвращают подключение новых сеансов к экземпляру:

  1. shutdown normalили просто shutdown: ждет отключения всех сеансов. Этот режим редко используется на практике, потому что он опирается на клиентов с хорошим поведением, которые не оставляют соединения открытыми. Раньше это был единственный shutdownрежим, который не отменял выполнение транзакций.
  2. shutdown transactional: отключает сеансы после завершения текущих транзакций, предотвращая начало новых транзакций.
  3. shutdown immediate: немедленно отключает все сеансы и откатывает прерванные транзакции перед завершением работы. Обратите внимание, что отключение происходит немедленно, но завершение работы может не происходить, так как выполнение любых прерванных транзакций может потребовать времени для отката.

Четвертый режим shutdownесть shutdown abort. Это как потянув за шнур питания - экземпляр останавливается в настоящее время без какой - либо очистки. Вы обычно хотите снова запустить базу данных и сразу же после нее полностью отключиться, как в вашем примере. Руководство по концепциям гласит :

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

Все примеры, которые вы приводите, выполняют контрольную точку как часть shutdown [normal]или shutdown immediateоколо того явной контрольной точки, предположительно, чтобы уменьшить время, необходимое для восстановления .

общий совет:

  • Не используйте shutdown normal.
  • Используйте только shutdown transactional для отключения при посещении , когда вы хотите минимизировать отмененные транзакции (только при посещении, потому что этот вид завершения не гарантирует отключение базы данных вообще, если превышены тайм-ауты).
  • Используйте shutdown immediateдля автоматического отключения или когда вам не нужны текущие транзакции.
  • Не используйте shutdown abort(плюс запуск / выключение) без необходимости - это было более распространено в более ранних версиях Oracle, чем сегодня. В других ситуациях (не исправлениях / обновлениях), если у вас есть необходимость минимизировать время простоя, этот режим может быть подходящим.

Можете ли вы предоставить более подробную информацию о недостатках shutdown abort? Разыгрывая антагониста, если мы можем доверять Oracle для правильного восстановления при отключении питания, разве мы не должны доверять ему во время a shutdown abort, особенно если это быстрее и мы собираемся немедленно сделать a startup restrictи a shutdown immediate? Другими словами, есть ли факты, которые мы можем увидеть, чтобы поддержать страшное предупреждение Oracle shutdown abort?
Ли Риффель

@Leigh - единственная особая опасность, о которой я знаю, shutdown abortкасается случайного резервного копирования сетевых журналов, но это только в том случае, если впоследствии вы не выполните чистое отключение. Если вы знаете, что делаете, я думаю, что shutdown abortэто можно считать совершенно безопасным - и я не уверен, что позиция Oracle считается «ужасным предупреждением» ;-)
Джек говорит, что попробуйте topanswers.xyz

3

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

  • воссоздать базу данных controlfile с помощью команды создания контрольных файлов (для переименования базы данных, переименования файлов журнала или переименования файлов данных)
  • изменить dbid с помощью процедуры из dbms_backup_restore (это был единственный метод в 8i для изменения dbid)

в обоих случаях база данных была повреждена и должна быть восстановлена ​​из полной резервной копии.

начиная с 9i, ​​переименование базы данных или изменение базы данных можно выполнить с помощью утилиты dbnewid . насколько я знаю, утилита проверяет, правильно ли была отключена база данных. переименование файлов данных, временных файлов и файлов журналов можно выполнить, выполнив соответствующие операторы sql без повторного создания контрольного файла.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.