「Oracle」カテゴリーアーカイブ

Oracle:プロセス構造の仕組み

Oracle DBのプロセス構造は大きく「ユーザープロセス」、「サーバープロセス」、「バックグラウンドプロセス」があります。

ユーザープロセス

  • クライアントからSQLを発行すると発生するプロセスです。

サーバープロセス

  • クライアントが発行したSQLを処理するするのがメインのプロセスです。

バックグラウンドプロセス

  • サーバープロセスがSQL管理に専念させるため、他のプロセスを監視するためのプロセスです。Oracleインスタンスを起動することで自動で起動します。
  • 主なバッググランドプロセスの種類
    種類説明
    DBWn
    (データベースライター)
    データベースバッファキャッシュ内の変更されたデータをデータファイルへ書き込む
    LGWR
    (ログライター)
    REDOログバッファにあるREDOログをREDOログファイルへ書き込む
    CKPT
    (チェックポイント)
    チェックポイント情報を制御ファイルとデータファイルヘッダーへ書き込む
    SMON
    (システムモニター)
    インスタンスのリカバリを実行する
    PMON
    (プロセスモニター)
    ユーザープロセス障害からリカバリを実施する
    ARCn
    (アーカイバー)
    REDOログファイルのコピー(アーカーブファイル)を作成する
    REDO
    (リカバラ)
    分散トランザクションに関する障害を自動的に解決する。
    MMON
    (マネージメントモニター)
    メモリー内の統計情報をスナップショットとして定期的にデーターベースへ格納する。
    MMAN
    (メモリーマネージャ)
    メモリーを必要な場所に動的に割り当てる

 

Oracle:最大プロセス数や最大セッション数を変更する方法

Oracleでのセッションやプロセス数には上限があり、それを超えてしまうとデータベースにアクセス出来ずに予期せぬエラー(ORA-12519)が発生するなどの不具合が発生してしまいます。

Oracleで最大プロセス数や最大セッション数は初期化パラメータを管理しているSPFILEに定義されています。変更前にSPFILEのバックアップを取得しておくのをオススメします。

SPFILEの配置場所

Oracle DB 18cの場合の例です。

  • 配置位置:[ORACLE_HOME]/database/SPFILE[ORACLE_SID].ORA
    (例)C:\ORACLE\WINDOWS.X64_180000_db_home\database\SPFILEORCL.ORA

最大プロセス数、最大セッション数の変更方法

  1. 最初に「V$SYSTEM_PARAMETER」から現在の最大プロセス数と最大セッション数の設定値を確認します。「V$SYSTEM_PARAMETER」はインスタンスに現在有効になっている初期化パラメータ情報を示します。

  2. 次にALETER文でプロセス数の上限を変更します。
  3. SPFILEの変更はOracleを再起動しないと適用されないため、Oracle DBを再起動します。
    詳細は「Oracle Database(Oracleサーバ)の再起動(停止・起動)手順」参照
  4. 再度プロセス数とセッション数を確認すると上限が変更されているのが確認出来ます。セッション数は明示的に変更しなくてもプロセス数の変更に比例して上限が増えます。

補足

なお、今回ご紹介した Oracle Database における「最大プロセス数(PROCESSES)」および「最大セッション数(SESSIONS)」の変更手順については、環境や用途によって最適値が異なります。以下の点にご留意ください。

  • 本番環境では、まずテスト環境で変更を検証したうえで適用することをおすすめします。変更後の再起動により影響が出る可能性があります。

  • PROCESSES の値を単に増やせば良いわけではなく、実際の接続数・負荷・リソース使用量を定期的にモニタリングする必要があります(例:V$SESSION、V$PROCESS、V$RESOURCE_LIMIT など)。

  • セッション数(SESSIONS)は PROCESSES の設定に影響を受けており、一般に「SESSIONS ≒ PROCESSES × 1.1〜1.2」のような目安が用いられますが、具体的には接続方式やアプリケーション構成によって変動します。

  • 多数のプロセスを許容する設定にする際は、サーバーのメモリ・CPU・I/Oリソースに対する影響も併せて考慮する必要があります。負荷のピーク時にはリソース競合が起きやすくなります。

  • 万一、変更前の値に戻す必要が生じた場合は、適用後のログやパフォーマンス指標を保持しておくことで、トラブルシューティングが容易になります。

以上を踏まえ、環境に適した値の設定および運用体制を整えたうえでパラメータ変更を実施して頂ければと思います。安心して運用を続けるための一助となれば幸いです。

Oracle:年、月、日、時、分、秒以下を切り捨てて取得する方法

OracleではTRUC関数を使用することで年、月、日、時、分、秒以下を切り捨てて取得することが可能となります。

使用例

サンプルテーブル「BIRTHDAY」

クエリー(SQL)

  • BIRTHDAYテーブルのUPDATE_DATEに対してTRUNC関数を使用した例となります。第2引数へformatを指定することで指定した単位で切り捨てた値を取得することが出来ます。
  • formatの種類 
    format説明
    YYYY年まで取得して月日時分秒を切り捨て
    MM年月まで取得して日時分秒を切り捨て
    DD年月日まで取得して時分秒を切り捨て
    HH年月日時まで取得して分秒を切り捨て
    MI年月日時分まで取得して秒を切り捨て
     

出力結果

 

Oracle:管理者ユーザー「SYS」と「SYSTEM」のデフォルトパスワード

Oracle 初期パスワードとは?

Oracle 初期パスワードを確認したい/変更したい場合、多くのバージョンで仕様が異なるため注意が必要です。この記事では Oracle の初期アカウント(SYS・SYSTEM)について、パスワードの扱いと安全な運用方法を解説します。

SYSユーザーのデフォルトパスワード:change_on_install

  • sysユーザーでのログイン例です。

SYSTEMユーザーのデフォルトパスワード:manager

  • systemユーザーのログイン例です。

Oracle:管理者ユーザー「SYS」と「SYSTEM」のデフォルトパスワード

ユーザー初期パスワード例備考
SYSchange_on_installデータディクショナリを管理する最上位アカウント
SYSTEMmanager一般的な管理作業に使用可能な補助アカウント

セキュリティ上の注意点

変更必須

デフォルトのままでは外部からの攻撃に悪用されやすいため、必ずパスワード変更を行うこと。

最近の Oracle バージョンでの違い

  • 11g 以降:インストール時にユーザーが必ずパスワードを指定。

  • 12c 以降:パスワードポリシーが強化され、英数字・記号混在の複雑なものを要求。

  • 19c/21c:初期アカウントはロック状態になっている場合も多い。

補足:運用時の留意点と実践アドバイス

本稿でご紹介したように、デフォルトユーザー「SYS」「SYSTEM」の初期パスワードが設定されたまま運用を開始することは、非常に高いセキュリティリスクを伴います。特にネットワークに接続された環境やクラウド/仮想化されたデータベースでは、外部からの侵入・横展開の入口になり得ます。

そこで、実運用にあたっては以下の点もあわせてご検討ください:

  1. パスワード変更/ロックダウンの徹底
    ・前述の SQL コマンド(ALTER USER … IDENTIFIED BY …)で直ちに適用するだけでなく、変更したパスワードは社内ポリシーに基づき「使い捨て・非共有」設計としてください。
    ・可能であれば、管理者ユーザーを使用せずに特権を限定した別ユーザーを作成し、SYS/SYSTEM アカウントは緊急対応用にのみ残すと良いでしょう。

  2. アクセス制御・監査ログの有効化
    ・データベースに対するアクセスを IP・ネットワーク・時間帯別に制限することで、万一パスワードが流出しても被害を抑制できます。
    ・また、誰がいつどのユーザーでログイン/DDL/DMLを実行したかを追えるように監査ログを有効化することも推奨されます。

  3. バージョン・ポリシーの理解
    ・本記事でも触れられている通り、Oracle Database のバージョンによって初期アカウントの仕様(パスワード必須・アカウントロック等)が異なります。例えば 11g 以降、12c/19c ではより強固なパスワードポリシーと自動ロック機能が導入されています。 Write Remember
    ・そのため、運用している環境のバージョンを把握し、初期設定のまま稼働していないか定期的に確認することが重要です。

  4. 定期的なレビューと脆弱性対策
    ・初期アカウントだけでなく、標準サンプルスキーマやテスト用ユーザーも残していないかチェックしてください。攻撃者は「資料通りに」残された穴を狙う傾向があります。
    ・さらに、データベース自体だけでなく OS/ミドルウェア/接続前段のネットワーク構成も含めた総合的なセキュリティレビューを年1〜2回実施することを推奨します。

  5. 万一のインシデント対応準備
    ・万が一、アカウントの不正使用やパスワード流出が疑われた場合の初動手順をあらかじめ策定しておくと、被害の拡大を防ぐことができます。
    ・例えば、アカウントの即時ロック/パスワード強制リセット/ログの取得・分析/改ざんの有無確認などを、運用マニュアルに定義しておくと安心です。

最後に、本稿の内容をただ「変更・実施すれば終わり」とせず、定期的な「運用の振り返り」と「改善サイクル」の一部として組み込むことが、真に安全なデータベース運用の鍵になります。ぜひ、日常運用の中で今回の注意点を意識し、安心・安全な環境構築に役立ててください。

SQL:システム日付と誕生日を元に年齢、誕生日までの月数、日数を表示する方法

SQLでシステム日付、誕生日を使用して年齢、システム日付~誕生日までの月数、日数を取得するSQLをメモしておきます。

以下はOracleでの実行例となっています。

サンプルテーブル

「BIRTHDAY」テーブル

【Oracle】システム日付と誕生日から年齢、誕生日までの月数、日数を表示する例

クエリー(SQL)例

実行結果

Oracle:DESCRIBEコマンドでテーブル(表)構造を確認する方法

SQL PlusやSQL Developerに用意されている「DESCRIBE」コマンドを使用することでテーブル構造を確認することが出来ます。

DESCRIBEコマンドはDESCと省略することも出来ます。

SQL PlusでのDESCRIBEコマンド実行例

  • 「DESCRIBE テーブル名」でテーブル構造が確認できます。

SQL PlusでのDESCコマンド実行例

  • DESCでもDESCRIBEと同じ結果を取得できます。

Oracle:接続時に「ORA-01109:データベースがオープンされていません。」エラーが出た場合の原因と対応方法

DBクライアントソフトなどでOracle DBへ接続時に「ORA-01109:データベースがオープンされていません。」が表示された場合の原因と対応方法についてメモしておきます。

「ORA-01109:データベースがオープンされていません。」の原因

  • 文字通り接続しようとしているDBがオープンされていないのが原因となります。今回接続先を「ORCLPDB」に指定していましたがそこがオープンされていないようです。
  • 念のためSQL Plusを起動して「show pdbs」コマンドでプラガブル・データベース(PDB)のオープン状態を確認するとやはりオープンされていませんでした。

「ORA-01109:データベースがオープンされていません。」の対処方法

  1. SQL Plusで「alter pluggable database ORCLPDB open;」コマンドを実行し、ORCLPDBをオープンします。
  2. 「show pdbs」コマンドでプラガブル・データベース(PDB)のオープン状態を確認します。
  3. これでORCLPDBのオープンだけなら完了していますが、このままPCを再起動するとまた再びクローズ状態に戻ってしまいます。ですので最後に現在オープンされている全てのPDBを自動起動(オープン)するように「alter pluggable database all save state;」コマンドで保存します。

 

補足:よくある注意点と確認ポイント

上記の対応だけで解決しない場合や、環境によっては以下のようなケースもあるので参考にしてください。

PDB が自動で開かない場合

ALTER PLUGGABLE DATABASE ALL SAVE STATE; を実行しても、再起動後に PDB が自動的にオープンされないことがあります。
その際は以下を確認してみてください。

  • PDB の AUTO_STARTUP が有効になっているか
  • 初期化パラメータ ENABLE_PLUGGABLE_DATABASE が設定されているか
  • OS 側の起動スクリプトに PDB オープン処理が含まれているか

権限不足でエラーになる場合

PDB を開こうとしたときに ORA-01031: insufficient privileges が出る場合は、権限不足の可能性があります。
SYSDBA 権限を持つユーザーで接続して実行する必要があります。

PDB の状態確認

今の状態を確認したいときは、次のコマンドを使うと便利です。

READ WRITE であればオープン済み、MOUNTED ならまだ開いていない状態です。

ログのチェック

もし原因が分からない場合は、アラートログ(alert log)や trace ファイルを確認してみてください。
「ファイルが読み込めない」「整合性が取れていない」といったエラーが記録されていることもあります。

冗長構成を利用している場合

Data Guard や RAC のような構成では、PDB のオープン状態が自動で引き継がれないことがあります。
フェイルオーバー後に PDB が閉じたままになるケースもあるので注意が必要です。

関連するエラーメッセージ

今回の ORA-01109 以外にも、以下のエラーが一緒に出ることがあります。

  • ORA-01110

  • ORA-01113

これらも「データベースがオープンされていない」状態に関係するため、併せて確認してみてください。

SQL:WHERE句内で「(+)」を指定する意味

SQLを見てるとたまにWHERE句内で「(+)」と記載されているのを見かけることがあります。

この「(+)」はOracle独自で記載が可能となる外部結合演算子といって、「g.GOODS_CODE = gt.GOODS_CODE(+)」のように指定するとLEFT OUTER JOINと同じ結果を取得することが出来ます。

サンプルテーブル

  • 「GOODS」テーブル
  • 「GOODS_TYPE」テーブル

外部結合演算子を利用したクエリー(SQL)例

通常の左外部結合でのクエリー(SQL)例

実行結果

外部結合演算子、左外部結合どちらも同じ結果となります。

補足

  • 「(+)」演算子の歴史的背景
    Oracle の古いバージョンからサポートされていた外部結合の書き方で、ANSI SQL 標準が普及する以前によく使われていました。ANSI 標準(LEFT JOIN / RIGHT JOIN / FULL OUTER JOIN)が登場して以降は、可読性・移植性の観点から推奨されないことが多いです。

  • 制限・注意点

    1. 可読性・保守性g.GOODS_CODE = gt.GOODS_CODE(+) のような記述は、JOIN の方向やどのテーブルに外部結合をかけているかが分かりにくく、後でクエリを読む人が迷いやすいです。

    2. 複雑な結合:複数テーブルを結合する場合、どこに (+) を付けるか、また付け方によって結果が変わるため、注意深く設計する必要があります。

    3. NULL の扱い:外部結合によって NULL が返る行が含まれますが、条件節で他の条件と組み合わせると意図しない行の除外が起きることがあります(例えば WHERE 節で AND 条件として別の非 NULL 条件を加えると外部結合の意味が薄れる等)。

  • ANSI 標準との違い

    項目 (+) 外部結合演算子 ANSI SQL 外部結合 (LEFT OUTER JOIN 等)
    可読性やや分かりにくい比較的分かりやすい
    移植性Oracle に依存多くの RDBMS でサポートされる
    複雑な JOIN の組み立てエラーや誤解の元になりやすいON 句で明示的に指定できるため制御しやすい
    サポート状況最新 Oracle でも非推奨の方向推奨される方式
     

  • 現代のベストプラクティス

    • 新規開発では ANSI SQL の外部結合構文を使うことを推奨。可読性や他 DBMS への移植性が高いため。

    • 既存システムで (+) を使っているなら、リファクタリングやドキュメント整備を行い、「なぜこの構文になっているか」「どのような影響があるか」を明らかにしておく。

    • テストを用意して、クエリ変更後に結果が同じになることを検証する(特に NULL の扱いや結合の漏れが起きていないか)。

  • 実際の書き換え例

    旧構文を ANSI 標準に書き換えるときの例をもう一つ:

     
    -- 旧構文

    -- 書き換え後(ANSI 標準)

    このように、結合条件を ON に書き出すことで構造が明瞭になります。

  • 互換性・移行のヒント

    • Oracle のバージョンによっては (+) 構文が将来削除される可能性があり、非推奨の警告が出ることもあります。

    • 他の RDBMS(PostgreSQL、MySQL、SQL Serverなど)で同じSQLを使うことを想定するなら、ANSI JOINに統一しておくと移行がスムーズです。

    • クエリのパフォーマンスにも注意。古い構文でも Oracle のオプティマイザが合理化する場合がありますが、可視性や保守性を取る方が長期的には有利。

Oracle:ユーザー作成時に「ORA-65096」エラーが出た場合の原因と対応方法

Oracleのインストール後にSQL*Plusなどでユーザー作成しようとした際、「ORA-65096」エラーが発生した場合の原因と対応方法についてメモしておきます。

「ORA-65096:共通ユーザーまたはロール名が無効です」の原因

  • ルートコンテナにローカルユーザーを作成しようとした場合に発生するエラーとなります。
    ルートコンテナには共有ユーザー(common user) と呼ばれる特殊なユーザーしか作成することはできません。
    Oracle 11gまでと違いOracle 12c以降からは一つのインスタンスには一つのコンテナ・データベース(CDB)と、プラガブル・データベース(PDB)と呼ばれる子DBが存在しています。sysなどのユーザーでログイン直後はコンテナ・データベース(CDB)に接続されている状態となっているため、そのままローカルユーザーを作成しようとしてもエラーが発生してしまうということになります。

「ORA-65096:共通ユーザーまたはロール名が無効です」の対処方法

原因が分かってしまえば対応はシンプルです。接続先がコンテナ・データベース(CDB)であるのがまずいのであればプラガブル・データベース(PDB)に変更してしまえばいいだけです。

  1. まずは「show con_name;」で現在接続されているデータベースを確認します。
  2. 次に「select name, open_mode from v$pdbs;」でPDBの名前と現在のOPEN_MODEを確認します。
  3. PDBの名前が「ORCLPDB」というのがわかったのでデータベースの接続先を「ORCLPDB」へ変更します。
  4. もう一度「show con_name;」を実行して接続先が変更されていることを確認します。
  5. 接続先がPDBへ変更されたのでもう一度ユーザー作成を実行すると正常に実行されます。

 

🔍補足:ORA-65096エラーの仕組みと注意点

ORA-65096: invalid common user or role name は、マルチテナント構成の Oracle Database(12c以降) において、
ルートコンテナ(CDB$ROOT)上でローカルユーザーを作成しようとした場合に発生するエラーです。
以下のポイントを押さえておくと、再発を防ぎやすくなります。

観点 内容
エラーの本質 共通ユーザーとローカルユーザーの区別を誤ったことによる構文エラー
共通ユーザー名の規則 C## または c## のプレフィックスが必須(COMMON_USER_PREFIXパラメータで変更可)
発生条件 CDB$ROOT に接続したままユーザーを作成/命名規則を満たさない場合
解決策 ALTER SESSION SET CONTAINER = <PDB名> でPDBに切り替えてから CREATE USER を実行する
参考 SHOW CON_NAME; で現在の接続先(コンテナ)を確認可能

✅ 具体例:安全なユーザー作成手順

もしルートコンテナ側で共通ユーザーを作成したい場合は、以下のようにします。


💡補足メモ

  • SHOW PDBS; で現在のPDB一覧を確認可能。OPEN_MODEREAD WRITE でなければユーザー作成はできません。

  • バージョン19c以降では、CDB構成がデフォルトのため、PDB接続の意識が必須 です。

  • TNS接続文字列(SERVICE_NAME)が CDB を指していると、意図せずルート側に接続してしまうことがあります。