Вимкнення бази даних перед оновленням або виправленням може бути виконано декількома способами.
shutdown immediate;або
shutdown abort;
startup restrict;
shutdown immediate;або
shutdown abort;
startup restrict;
shutdown;або
alter system checkpoint;
shutdown abort;
startup restrict;
shutdown immediate;Звичайно, є й інші варіанти. Кому слід віддати перевагу і чому?
Відповіді:
Мета при відключенні для обслуговування (або холодного резервного копіювання) полягає в тому, щоб база даних залишалася в послідовному стані, не потребуючи відкату / відновлення при запуску.
Існують 3 shutdownкоманди SQL * Plus, які теоретично досягають цього, і всі вони негайно перешкоджають підключенню до сеансу нових сеансів:
shutdown normalабо просто shutdown: чекає відключення всіх сеансів. Цей режим дуже рідко використовується на практиці, оскільки він покладається на доброзичливих клієнтів, не залишаючи з'єднання відкритими. Це був єдиний shutdownрежим, який не скасовував запущені транзакції.shutdown transactional: відключає сеанси після завершення поточних транзакцій, запобігаючи початку нових транзакцій.shutdown immediate: негайно відключає всі сеанси та скасовує перервані транзакції перед тим, як вимкнутись. Зауважте, що відключення негайні, але відключення може не бути, оскільки будь-які перервані транзакції можуть зайняти час, щоб повернути їх назад.Четвертий режим shutdownє shutdown abort. Це як витягнути шнур живлення - екземпляр зупиняється зараз без будь-якого очищення. Зазвичай ви хочете після цього знову відновити базу даних та одразу після цього чисто закрити, як у вашому прикладі. Посібник з понять говорить :
Цей режим призначений для надзвичайних ситуацій, наприклад, коли жодна інша форма відключення не вдається.
Усі приклади, які ви наводите, виконують контрольну точку як частину shutdown [normal]або shutdown immediateтак явної контрольної точки, імовірно, для скорочення часу, необхідного для відновлення .
загальна порада:
shutdown normal.shutdown transactional для відключеного відвідування , якщо ви хочете мінімізувати скасовані транзакції (відвідувались лише тому, що подібне відключення не гарантовано взагалі закривати базу даних, якщо порушуються тайм-аути).shutdown immediateдля автоматичного відключення або коли вам не байдуже поточні операції.shutdown abort(плюс запуск / вимкнення), якщо вам не доведеться - це було більш часто зустрічається в набагато більш ранніх версіях Oracle, ніж сьогодні. В інших ситуаціях (не виправлення / оновлення), якщо у вас є необхідність мінімізувати час простою, цей режим може виявитися доречним.shutdown abortстосується випадкового резервного копіювання онлайнових журналів, але це лише у випадку, якщо ви згодом не зробите чисте відключення. Якщо ви знаєте, що ви робите, я думаю, що shutdown abortце можна вважати цілком безпечним - і я не впевнений, чи позиція Oracle вважається "жахливим попередженням" ;-)
Я вважаю за краще метод припинення переривання, тому що це найшвидший спосіб збити базу даних. є деякі операції, які неможливо виконати після припинення відключення, наприклад
в обох випадках база даних була пошкоджена і повинна бути відновлена після повної резервної копії.
з 9i перейменування бази даних або зміна dbid можна виконати за допомогою утиліти dbnewid . наскільки я знаю, утиліта перевіряє, чи правильно було відключено базу даних. перейменування файлів даних, тимчасових файлів і журналів можна виконати шляхом виконання відповідних операторів sql, не відтворюючи звичайно файл керування.
shutdown abort? Граючи в антагоніста, якщо ми можемо довіряти Oracle, щоб він відновився правильно, коли енергія витягнута, чи не слід йому довіряти під часshutdown abort, особливо якщо це швидше, і ми збираємось негайно робити «startup restricta»shutdown immediate? Іншими словами, чи є факти, які ми можемо бачити, щоб підкріпити жорстоке попередження Oracleshutdown abort?