はじめに
こんにちは！ゆうきです🤗
これまでの記事
「ひとりでできるもん」シリーズはいかがでしたでしょうか？
●Tera Termってなぁに??
●仮想Linuxサーバってなぁに??
●Linuxひとりでできるもん
関連記事になりますのであわせてご覧くださいね。
今回はデータベースの使い方を紹介していきたいと思います🍀
本記事では、実機操作を通して情報処理技術の理解を深めることを目的としており、
皆様の環境での動作を保証するものではありません。👀
停止起動の流れ
Oracleデータベースは、24時間起動して運用されている場合が多いです。
ところが、サーバの機器が故障したり、停電などの影響で
計画的にデータベースを停止しなければならないことがあります。
停止と起動のベースとなる手順は次の通りです。
停止
・データベースのプロセスを確認
・停止するデータベースにsysdba権限でアクセス
・停止するデータベースが想定通りか確認
・アラートログを監視
・データベースにshutdownコマンドを実行
・データベースのプロセスを確認
停止した状態のメンテナンスを実施する
起動
・データベースのプロセスを確認
・起動するデータベースにsysdba権限でアクセス
・アラートログを監視する
・データベースにstartupコマンドを実行
・起動したデータベースが想定通りか確認
・データベースのプロセスを確認
確認が多いと感じる方もいらっしゃるかもしれませんが、
システムで監視していても、それとは別に
データベースエンジニアが手動で確認しておくことで、
何かあったときの状況把握が迅速確実になります🤗
監視しなければならない項目を挙げればまだまだありますが、
現場の状況に応じてアレンジください⭐
データベースを停止する
データベースのプロセスを確認
以下のように、停止する インスタンス の名前を検索対象に指定して
コマンドを実行して、OSでデータベースの プロセス が起動していることを確認します。
ps -aef | grep _orcl | grep -v grep
実行結果の一部を切り出したものが以下の通りです。
oracle 31322 1 0 13:47 ? 00:00:00 ora_w006_orcl oracle 31327 1 0 13:47 ? 00:00:00 ora_w007_orcl oracle 31906 1 0 13:57 ? 00:00:01 ora_m001_orcl [oracle@localhost ~]$
データベースが停止している場合は、検索結果に該当プロセスが表示されません。
今回挙げた検索コマンドの仕組みについて触れておくと、
「|」を使うと左のコマンドの 標準出力 を、
右のコマンドの標準入力に渡します🍀
「ps -aef」コマンドは、OSで起動しているプロセスの一覧を出力します。
「grep _orcl」コマンドで、psコマンドで出力された内容から、
運用しているデータベースのインスタンス名と
関連するプロセスだけを検索して出力します。
「grep -v grep」コマンドは、インスタンス名のgrepコマンドで検索したプロセスが
検索結果に表示されてしまうため、不要な表示を消して
結果を見やすくするために実行します。
必須ではありませんが手順に含めておくと結果が見やすくなります。
・「grep -v grep」コマンドなし
[oracle@localhost ~]$ ps -aef | grep _orcl oracle 4014 1 0 15:10 ? 00:00:00 ora_m003_orcl oracle 4343 1 0 15:15 ? 00:00:00 ora_m000_orcl oracle 4458 1 0 15:17 ? 00:00:00 ora_m004_orcl oracle 4737 29328 0 15:21 pts/1 00:00:00 grep --color=auto _orcl oracle 30409 1 0 13:37 ? 00:00:00 ora_pmon_orcl oracle 30411 1 0 13:37 ? 00:00:00 ora_clmn_orcl
・「grep -v grep」コマンドあり
[oracle@localhost ~]$ ps -aef | grep _orcl | grep -v grep oracle 4014 1 0 15:10 ? 00:00:00 ora_m003_orcl oracle 4343 1 0 15:15 ? 00:00:00 ora_m000_orcl oracle 4458 1 0 15:17 ? 00:00:00 ora_m004_orcl oracle 30409 1 0 13:37 ? 00:00:00 ora_pmon_orcl oracle 30411 1 0 13:37 ? 00:00:00 ora_clmn_orcl
検索をするために、grepプロセスが起動してそれが検索結果に表示されるのですが、
「grep -v grep」に渡すことでそのプロセスが表示されなくなりましたね👀
一台のマシンで多数の インスタンス が起動している場合は
先に紹介した確認に加えて、接続先を間違えたりなどの操作ミスで
他の インスタンス に影響を及ぼしていないかを簡易的にすばやく確認するために
pmonプロセスなどに絞ってgrepしたりするなどの確認方法も有効です🍀
[oracle@localhost ~]$ ps -aef | grep _pmon oracle 5575 29328 0 15:34 pts/1 00:00:00 grep --color=auto _pmon oracle 30409 1 0 13:37 ? 00:00:00 ora_pmon_orcl oracle 30509 1 0 13:37 ? 00:00:00 ora_pmon_orcldev oracle 30609 1 0 13:37 ? 00:00:00 ora_pmon_orcltest
停止するデータベースにsysdba権限でアクセス
データベースにsysdba権限でアクセスする際のルールは、
現場によって定義されている場合があるので、
みなさまの環境でのルールに従って手順を実行してくださいね👀
最も簡易なものとして一例を以下に記載いたします。
[oracle@localhost ~]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Mon Jul 6 16:00:03 2020 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL>
停止するデータベースが想定通りか確認
最も大切な確認項目です。
ここで確認漏れがあると大事故につながる恐れがあります。
以下のコマンドをsqlplusで実行して、ホスト名およびインスタンス名をよく確認しましょう。
select host_name, instance_name, status from v$instance;
ホスト名とインスタンス名で、
データベースを一意に特定できないシステムも世の中にはあります。
あらかじめシステムの特性を理解して確認項目をアレンジしてください😌
アラートログを監視する
データベースは アラートログ に動作が記録されます。
リアルタイムにログを確認しながら作業するために、
Tera Termウィンドウを新たに起動して、二つを並べて操作しましょう🍀
tailというコマンドを以下のように使用して、 アラートログ の監視を開始します。
なお、tailコマンドを実行した後は、Enterキーを入力すると
行間をあけることができます。
どこからが監視を始めたタイミングかわかりやすいように、
複数行改行を入れておくと見やすくなるでしょう👀
cd /opt/oracle/base/diag/rdbms/orcl/orcl/trace tail -f alert_orcl.log
作業イメージは以下の画像のような状態になります。
アラートログ の配置先は、データベースのインストールOSやバージョンによって異なります。
Linuxインストールのデータベースバージョン19cではデータベースのdiagnostic_destパラメータのパス配下に格納されています。
SQL> show parameter diag NAME TYPE ------------------------------------ --------------------------------- VALUE ------------------------------ diagnostic_dest string /opt/oracle/base SQL>
データベースにshutdownコマンドを実行
上に記載した確認項目が想定通りおよび正常に実行できた場合、
停止の準備は完了です❗
実際にデータベースを停止していきましょう。
shutdownコマンドの詳細についてはマニュアルを参照して確認しておきましょう
管理 → 管理者ガイド → 第I部 基本データベース管理 → 3 起動と停止
を参照します。
SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL>
停止に失敗した場合、sqlplusにエラーが出力されるだけでなく、
アラートログ でも停止プロセスのどこで失敗したかがわかります。
シャットダウンには何十分もかかる場合があります👀
慌てて判断を間違えないように、落ち着いて対応しましょう。
データベースのプロセスを確認
前述した手順と同様に確認して、
検索結果にプロセスが表示されないことを確認します。
停止した状態のメンテナンスを実施する
データベースを停止したときにしかできないメンテナンスがある場合、
停止機会があると、まとめてメンテナンスする場合が多いです😌
サーバ筐体のメンテナンスや、 初期化パラメータ の調整など、
必要なメンテナンスを実施して確認しましょう。
データベースを起動する
データベースのプロセスを確認
前述した手順と同様に確認して、
検索結果にプロセスが表示されないことを確認します。
起動するデータベースにsysdba権限でアクセス
前述した手順と同様に接続します。
インスタンス が停止しているため、「Connected to an idle instance.」と表示される場合があります。
[oracle@localhost ~]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Fri Jul 10 17:35:08 2020 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Connected to an idle instance. SQL>
アラートログを監視する
前述した手順と同様に監視して、
リアルタイムにログを確認できるようにします。
データベースにstartupコマンドを実行
上に記載した確認項目が想定通りおよび正常に実行できた場合、
起動の準備は完了です。
実際にデータベースを起動していきましょう。
SQL> startup ORACLE instance started. Total System Global Area 838858176 bytes Fixed Size 8902080 bytes Variable Size 591396864 bytes Database Buffers 234881024 bytes Redo Buffers 3678208 bytes Database mounted. Database opened. SQL>
起動したデータベースが想定通りか確認
停止する前と同じ状態か確認します。
ホスト名とインスタンス名は必ず確認しますが、
ここで重要になってくるのは、ステータスが「OPEN」になっていることです。
あわせてリアルタイムで監視している アラートログ にも
異常が検出されていないか、目で追えなかった部分もスクロールしてしっかり確認しましょう👀
[oracle@localhost ~]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Fri Jul 10 14:15:32 2020 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL>
データベースが破損した状態でstartupするとわかるのですが、
状態がOPENにならない場合があります。
OPENにならない場合は、sqlplusのログと アラートログ に原因が出力される場合が多いので、
原因を取り除くことでデータベースをOPENしていきます。
データベースのプロセスを確認
前述した手順と同様にコマンドを実行して、
OSでデータベースプロセスが起動していることを確認します。
おわりに
Oracleデータベースの停止起動の基礎の部分だけをご紹介しましたがいかがでしょうか。
私自身記事を書いてみて、スタンダードなところに絞っても
こんなに手順が多いのだと改めて感じました。
実際の現場では、今回ご紹介したシングルインスタンスでも、
データベース以外の操作が何段階も必要な場合が多くあります。
監視システムやクラスターシステムがあって
それぞれに分担された担当者がいて連携が必要な場合も多いです。
さらに、 HA や RAC や DataGuard などが構築されていたり
ASM や リスナー など、データベースを支える他のプロセスも考慮しなければなりません😌
この基本をおさえておけば、難しい構成のシステムでも、
どこの操作をしているのかよく考えることで理解の助けになります🍀
投稿者プロフィール
