Autonomous Databaseでの「アカウントがロックされています。」エラーについて

Autonomous DatabaseのAPEXワークスペースにサインインしようとしたときに、「アカウントがロックされています。」というエラーが表示されました。そのときの対処についての覚書です。

結果としては、APEXの管理サービスよりユーザーの編集を開いて、ロックを解除しました。

オンプレミスのAPEXのインストールでは、管理者および開発者もAPEX自体に登録されたユーザーなので、この対応になります。

Autonomous Databaseの場合、管理者および開発者ユーザーと同名のデータベース・ユーザーが作成され、そのユーザーのユーザー名とパスワードでデータベースで認証することで、APEXの開発ツールにサインインします（APEXのアプリケーションについては、APEXに保存されているパスワードにより認証されます）。そのため、データベース・ユーザーがロックされてると、同様に「アカウントがロックされています。」のエラーが発生します。

以下の問い合わせを発行し、ユーザーの状態を確認します。

select username, account_status, lock_date from dba_users where username = upper('ユーザー名')

この場合は、データベース・ユーザーのアカウントをアンロックすることで、事象は解消します。

alter user ユーザー名 account unlock;

APEXワークスペースに紐づくデフォルト・パーシング・スキーマもデータベース・ユーザーなので、アカウントはロックできます。Oracle APEXのアプリケーションは、アプリケーションに割り当てられたパーシング・スキーマの権限でSQLやPL/SQLを実行しますが、そのデータベース・ユーザーでデータベースに接続はしません。そのため、パーシング・スキーマのアカウントがロックされていても、アプリケーションは動作します。

データベース・アクション（SQL Developer Web）や、SQLclのようなツールでパーシング・スキーマのデータベース・ユーザーで接続する場合は、そのアカウントがロックされていると接続できません。

APEXの開発ツールにサインインする際に「アカウントがロックされています。」というエラーが発生した場合は、APEXユーザーのステータスとデータベースのユーザーのステータスの両方を確認する必要があります。

今回の記事は以上になります。

完

Autonomous Databaseで利用できるapex-adb-xxx擬似ヒントの確認

 Oracle APEXのレポートやチャートのソースに、オプティマイザ・ヒントを指定できます。このプロパティで指定できるオプティマイザ・ヒントには、データベースへのヒントではなくAPEXによって解釈されるヒントが含まれます。Oracle APEXでは擬似ヒントと呼んでいます。

Autonomous Databaseで使うことのできるapex-adb-high、apex-adb-medium、apex-adb-low、apex-adb-tp、apex-adb-tpurgentといった擬似ヒントがあるとのことで、確認してみました。

リソース・マネージャのコンシューマ・グループの切り替えは、以前の記事でCS_SESSION.SWITCH_SESSIONを呼び出して実装したことがあります。擬似ヒントの指定により切り替えができるのであれば、コンシューマー・グループの切り替えを簡単に実装できます。

確認作業に使用するアプリケーションを作成します。

アプリケーション作成ウィザードを起動します。

アプリケーションの名前を擬似ヒントの確認とし、ページの追加をクリックします。

ダイアログが開きます。追加ページを開き、クラシック・レポートを選択します。

ページ名はサービスの確認、SQL問合せを選択します。ページは、クラシック・レポートです。SQL問合せとして、以下を記述します。

select
    sys_context('USERENV','SID') sid
    , sys_context('USERENV','SESSIONID') audsid
    , sys_context('USERENV','SERVICE_NAME') service_name
from dual

ページの追加をクリックします。

アプリケーションの作成を実行します。

アプリケーションが作成されました。ページ・デザイナにて、ページ番号２のサービスの確認を開きます。

クラシック・レポートのリージョンサービスの確認を選択し、ソースのオプティマイザ・ヒントとしてapex-adb-mediumを指定します。

アプリケーションを実行し、クラシック・レポートの表示を確認します。

サービス名が切り替わっていることが確認できます。

擬似ヒントのスペルが間違っていてもエラーは発生しないので、注意が必要です。

デバッグの完全トレースを取得し、実行されているコマンドを確認します。

レポートのソースであるSELECT文が実行される前に、execution service levelとしてapex-adb-high、apex-adb-low、apex-adb-medium、apex-adb-tp、apex-adb-tpurgentがあることが確認されています。今回テストに使用しているインスタンスはAutonomous Transaction Processingなのでapex-adb-tp、apex-adb-tpurgentが含まれますが、Autonomous Data Warehouseの場合はapex-adb-high、apex-adb-low、apex-adb-mediumの３つと思われます。

この後alter session文を発行して、サービスを切り替えています。

executing switch service SQL: "alter session set container="XXXXXXXXXXXX_APEXSERV" service="XXXXXXXXXXXX_APEXSERV_medium.adb.oraclecloud.com""

レポートのSELECT文を実行した後に、元のexecution service levelに戻しています。

Autonomous Databaseで利用できるapex-adb-xxx擬似ヒントを、簡単に確認してみました。

簡単なアプリケーションですが、以下にエクスポートを置きました。

https://github.com/ujnak/apexapps/blob/master/exports/confirm-adb-psedudo-hint.zip

Oracle APEXのアプリケーション作成の参考になれば幸いです。

完

APEX 22.1で変更されたAutonomous Databaseでのワークスペース作成

 以前にAutonomous Databaseでのワークスペースの追加作成という記事で、Autonomous DatabaseでのAPEXワークスペースの作成手順について説明しました。

Autonomous DatabaseのAPEXがOracle APEX 22.1に上がった際に、APEXワークスペースの作成手順が変更されています。

以下より変更された手順を確認します。

管理サービスの説明「自律型データベースの管理者(ADMIN)パスワードを使用してサインインしてください。」に従って、ADMINのパスワードを入力し、管理にサインインをクリックします。

初回サインイン時はワークスペースが未作成のため、すぐにワークスペースを作成するダイアログが開きます。今回はワークスペースはすでに作成済みなので、ワークスペースを追加作成します。

ワークスペースの作成をクリックします。

ダイアログが開きます。新規のスキーマを選択します。

ワークスペースの作成のダイアログが開きます。

APEX 22.1以前のダイアログは以下です。

APEX 22.1から、以下のダイアログに変わりました。

ワークスペース名については、バージョンによらず双方ともAPEXのワークスペース名の指定になります。

以前あったデータベース・ユーザとパスワードの指定は無くなりました。

APEX 22.1からは、ワークスペースの管理者ユーザーとして作成されるデータベース・ユーザーと、データベース・オブジェクトなどを保持しデフォルト・パーシング・スキーマとなるデータベース・ユーザーは別に作成されます。

ワークスペース・ユーザー名およびパスワードとして、ワークスペースの管理者となるデータベース・ユーザーの名前とパスワードを指定します。このユーザーは、データベース・オブジェクトを保持しません。

データベース・オブジェクトを保持するスキーマとして、ワークスペース名に接頭辞としてWKSP_を付けたデータベース・ユーザーが作成されます。データベース・パスワードは、このユーザーに与えるパスワードです。sqlplusやSQLclといったツールから接続する要件がなければ、このパスワードを指定する必要はありません。

ワークスペースIDは、こちらの記事で説明しているように、開発、ステージング、本番といった異なる用途のインスタンスに作成するワークスペースで、ワークスペースIDを一致させる際に指定します。

ワークスペースの作成をクリックします。

作成されたワークスペースを確認します。

既存のワークスペースからは、ワークスペースHRが作成されていることが確認できます。

開発者とユーザーの管理を確認します。

ワークスペース管理者としてHRADMINが作成されています。ワークスペースはHR、デフォルトのスキーマとしてWKSP_HRが紐づけられています。

作成されたワークスペースにサインインします。

サインインには、ワークスペース名、ワークスペース・ユーザー名、ワークスペース・パスワードを指定します。データベース・ユーザー名（WKSP_HR）およびデータベース・パスワードではサインインできません。

SQLワークショップのSQLコマンドを開き、以下のSQLを実行します。

select 
    sys_context('userenv','session_user') as session_user, 
    sys_context('userenv','session_schema') as session_schema,
    sys_context('userenv','current_schema') as current_schema,
    sys_context('userenv','proxy_user') as proxy_user
from　dual;

SQLコマンドを実行するスキーマとして、右上の選択リストにWKSP_HRが選択されていることが確認できます。

Oracle APEXによるSQLの実行という解説記事を書いた当時は、APEXの処理であるプロシージャはSESSION_USERのORDS_PUBLIC_USERから呼び出されていました。これはセキュリティ強化を目的として、Oracle REST Data Servicesの処理と同様にORDS_PUBLIC_USERをプロキシとして通した上で、ユーザーORDS_PLSQL_GATEWAYにて実行されるように変わっています。

続けて、Oracle REST Data Servicesを有効にします。

Oracle REST Data Servicesを有効にするスキーマは、WKSP_HRになります。HRADMINではありません。

ORDSにスキーマを登録する際に、スキーマ別名をワークスペース名に一致するようにします。今回の例ではhrです。スキーマ名であるWKSP_HRはORDS RESTサービスのURLに現れません。

データベース・アクションから、作成されたデータベース・ユーザーを確認します。

RESTの有効化が行われているのはWKSP_HRです。そのため、データベース・アクションへの接続URLはデータベース・ユーザーWKSP_HRに対して生成されています。

リンクを開き、データベース・ユーザーWKSP_HRでADBに接続します。

画面が開きます。ここで入力するユーザーはAPEXワークスペースの管理者ユーザーとパスワードになります。

今回の例ではHRADMINとそのパスワードを入力します。

サインインにはAPEXワースクスペースの管理者ユーザーであるデータベース・ユーザーのユーザー名とパスワードを指定しましたが、データベース・アクションとしてはデータベース・ユーザーWKSP_HRとしてサインインされています。

以上より、Oracle APEXとデータベース・アクションの双方で、ワークスペースのスキーマWKSP_HRを直接指定して接続することはありません。

直リンクによる接続でない場合は、最初のユーザー名として、ORDS別名であるHRを入力します。

Oracle APEXおよびOracle REST Data Servicesの双方とも、実際にSQLを実行するユーザーはWKSP_HRになるため、grant文を呼び出して実行権限などを付与する対象は、WKSP_HRになります。

データベース・アクションには、Oracle APEXのワークスペースを管理する機能が追加されています。

画面右上に、ワークスペースの作成というボタンがあります。

現時点（2022年7月12日）のデータベース・アクションでは、データベース・ユーザー（スキーマ）の名前と、APEXユーザー名を同じ名前にしてAPEXワークスペースを作成します。これはAPEX側から見ると、APEX 22.1以前でのワークスペースの作成方法になります。

Autonomous Database上で動作するAPEX 22.1から、ワークスペースを新規作成する場合、スキーマにはWKSP_の接頭辞が付くことを理解した上で、Oracle APEXで扱うスキーマ名にWKSP_といった接頭辞は付けたくない場合は、APEXではワークスペースを新規作成せず、既存のスキーマを選択するか（あらかじめスキーマを作成するには、データベース・アクションでの作業が必要）、そのままデータベース・アクションからAPEXワークスペースを作成する必要があるでしょう。

APEX 22.1で変更された、Autonomous Databaseでのワークスペース作成についての説明は以上です。

完