Amazon RDS for Oracle DB インスタンスの ORA-00018 または ORA-00020 エラーを解決するにはどうすればよいですか?

簡単な説明

これらのエラーは、多数の DB 接続を引き起こす計画されたスケーリング、または予定外のイベントが原因で起きる場合があります。このような場合、DB インスタンスに対して多くのクライアントセッションが開始され、次のいずれかのデータベース制限に達します。

• PROCESSES – 許可されるユーザープロセスの最大数。
• SESSIONS – 許可されるユーザーセッションの最大数。

計画されたスケーリング演習のために最大接続数に達した場合は、SESSIONS もしくは PROCESSES、またはその両方を引き上げます。これにより、アプリケーションの新しいスケールに対応できます。この 2 つのパラメータは動的でないため、パラメータを変更してから、インスタンスを再起動する必要があります。

計画されていないイベントが原因で最大接続に達した場合は、そのイベントの原因を特定し、適切なアクションを実行します。

例えば、ロックまたはブロックの競合が原因で応答時間が長くなった場合は、アプリケーションによってデータベースに負荷がかかる場合があります。この場合、SESSIONS または PROCESSES を増やしても、再度最大値に達する前に接続数が増加するだけです。これにより、競合による問題が悪化する可能性があります。その代わり、これにより、Amazon RDS モニタリングシステムのログイン、ヘルスチェックの実行、再起動などの修正アクションの実行が防止されます。

解決方法

Oracle ユーザー PROFILE

ORA-18 と ORA-20 の最も一般的な原因の 1 つは、多数のアイドル接続です。アイドル接続は、アプリケーションまたはデータベース管理者によって適切に閉じられることなく、データベースに残ります。IDLE 接続が増えると、データベースが SESSIONS/PROCESSES パラメータの上限に達する可能性があります。その結果、新しい接続は許可されなくなります。アプリケーション接続については、制限した IDLE_TIME 値で PROFILE を設定するのがベストプラクティスです。

Oracle データベースでは、各ユーザーが PROFILE に割り当てられます。Oracle PROFILE は、この PROFILE にアタッチされた各ユーザーに割り当てられる一連のリソースです。それらのリソースの 1 つが IDLE_TIME です。IDLE_TIME は、クエリがデータベースによって強制終了される前に、セッション中に許可される連続的な非アクティブ時間を分単位で指定します。長時間実行されるクエリやその他のオペレーションには、この制限は適用されません。

この例は、最大 IDLE_TIME が 30 分間であるプロファイルを作成し、それをアプリケーションユーザーに割り当てる方法を示しています。30 分間を超える IDLE 接続は、データベースによって自動的に強制終了されます。

制限された IDLE_TIME パラメータで PROFILE を作成します。

SQL> select count(*) from v$session where type= 'BACKGROUND';

この PROFILE を特定のユーザーに割り当てます:

  SQL> ALTER USER <username> PROFILE <profile_name>;

RDS インスタンスサイズのスケーリング

アプリケーションユーザーからの着信ワークロードの増加により、SESSIONS/PROCESSES の最大数に達する可能性があります。RDS for Oracle のデフォルトでは、両方のパラメータ制限は DB インスタンスクラスのメモリに依存する事前定義済みの式に基づいて計算されます。この場合、SESSIONS/PROCESSES パラメータを手動で変更することはベストプラクティスではありません。代わりに、ワークロードに基づいてインスタンスをスケールアップ/ダウンします。

PROCESSES/SESSIONS パラメータの RDS のデフォルト設定は、次の式を使用して計算されます。

• PROCESSES= LEAST({DBInstanceClassMemory/9868951}, 20000)
• SESSIONS = Oracle のデフォルト = (1.5 * PROCESSES) + 22

PROCESSES または SESSIONS のいずれかのパラメータをデフォルトの制限を超えて手動で設定すると、メモリの消費量が増加する可能性があります。その結果、メモリ不足の問題によりデータベースがクラッシュする可能性があります。また、PROCESSES または SESSIONS を手動で設定すると、インスタンスのスケールアップ/スケールダウン時に設定が一致しなくなる可能性があります。これは、PROCESSES と SESSIONS パラメータが、割り当てられたインスタンスメモリに依存しなくなったためです。

LICENSE_MAX_SESSIONS

LICENSE_MAX_SESSIONS パラメータは、許可される同時ユーザーセッションの最大数を指定します。これは、Oracle のバックグラウンドプロセスや、DBA ロールを持つユーザーなどの RESTRICTED SESSION 権限を持つユーザーには適用されません。LICENSE_MAX_SESSIONS を、SESSIONS と PROCESSES よりも低い値に設定します。これにより、クライアント接続に対して、ORA-18 または ORA-20 エラーではなく、ORA-00019 エラーが表示されます。ORA-00019 エラーは、RESTRICTED SESSION 権限を持つユーザーには適用されません。そのため、プライマリユーザーと RDSADMIN ユーザーは DB インスタンスにログオンし、管理上のトラブルシューティングと修正アクションを実行できます。また、Amazon RDS モニタリングでは、RDSADMIN を使用してデータベースに接続し続け、ヘルスチェックを実行できます。

注: LICENSE_MAX_SESSIONS は当初、同時セッションの数に基づいて使用を制限することを意図していました。Oracle では、同時セッション数に基づくライセンスが提供されなくなり、LICENSE_MAX_SESSIONS は非推奨となりました。ただし、19c までの Oracle バージョンを使用する場合は、そのパラメータを使用できます。また、アプリケーションユーザーには DBA ロールまたは RESTRICTED SESSION 権限を付与しないでください。詳細な情報については、LICENSE_MAX_SESSIONS に関する Oracle ドキュメントを参照してください。

LICENSE_MAX_SESSIONS は動的パラメータのため、DB インスタンスを再起動せずに設定することができます。詳細については、「パラメータグループを使用する」を参照してください。

LICENSE_MAX_SESSIONS パラメータは、PROCESSES パラメータと同様に、式として設定できます。LICENSE_MAX_SESSIONS パラメータは、静的な値ではなく、式に基づいて設定するのがベストプラクティスです。これは、インスタンスサイズをスケールアップ/スケールダウンする際の設定ミスを防ぐのに役立ちます。例:

• PROCESSES パラメータと同じ設定にするには: LICENSE_MAX_SESSIONS= LEAST({DBInstanceClassMemory/9868951}, 20000)
• PROCESSES パラメータの 4/5 に設定するには: LICENSE_MAX_SESSIONS= LEAST({DBInstanceClassMemory/12336188}, 20000)

DEDICATED セッションを使用する

DEDICATED セッションを使用する場合は、クライアント接続が PROCESSES パラメータの制限を超えることがあります (ORA-20)。クライアント接続がこの制限を超える場合は、LICENSE_MAX_SESSIONS の値を PROCESSES より低い値に設定します。

• LICENSE_MAX_SESSIONS = クライアント接続のみの最大数。
• PROCESSES = LICENSE_MAX_SESSIONS + すべてのバックグラウンドプロセス (並列クエリなど)、DBA ユーザー (プライマリユーザーなど)、バッファ。バッファを使用することで、後に発生する可能性のある想定外のバックグラウンドプロセスを実行することができます。現在動作しているバックグラウンドプロセス数を確認するには、次のようなクエリを実行します。

SQL> select count(*) from v$session where type= 'BACKGROUND';

注: デフォルト値が (1.5 * PROCESSES) + 22 に設定されている SESSIONS は十分なはずです。詳細な情報については、SESSIONS に関する Oracle ドキュメントを参照してください。

インスタンスに手動で接続して SESSIONS を確認するには、次のようなコマンドを実行します。

SQL> select name, value from v$parameter where upper(name) in ('SESSIONS','PROCESSES','LICENSE_MAX_SESSIONS');
NAME   VALUE
------------------------------ ------------------------------
processes   84
sessions   148
license_max_sessions   0

SHARED セッションを使用する

SHARED セッションを使用する場合は、クライアント接続が SESSIONS パラメータの制限を超えることがあります (ORA-0018)。クライアント接続がこの制限を超える場合は、PROCESSES パラメータの値を今よりも高い値に設定します。

• LICENSE_MAX_SESSIONS = クライアント接続のみの最大数。
• PROCESSES = すべてのバックグラウンドプロセス (並列クエリなど)、DBA ユーザー (プライマリユーザーなど)、バッファ。SHARED_SERVERS と DISPATCHERS の設定に、必ずバックグラウンドプロセスの数を含めてください。
• SESSIONS = (1.5 * PROCESSES) + 22

SHARED サーバーを使用しており、最大セッション (ORA-18) エラーではなく最大プロセス (ORA-20) エラーが表示された場合は、DISPATCHERS が機能していない可能性があります。DISPATCHERS が機能していない場合、接続は DEDICATED になります。より多くのセッションが共有接続できるように、DISPATCHERS の数を増やします。SHARED_SERVERS パラメータも増やす必要がある場合があります。

SHARED サーバーと DEDICATED サーバーのどちらを使用しているかを確認するには、次のようなコマンドを実行します。

SQL> select decode(server, 'NONE', 'SHARED', server) as SERVER, count(*)
from v$session group by decode(server, 'NONE', 'SHARED',server)

---

関連情報

Oracle を使用するためのベストプラクティス