ロード・バランサの割り当て制限をAlways Freeの範囲にする

 Oracle CloudのAlways Free Cloud Servicesとして、Flexible Load Balancerが含まれています。

https://www.oracle.com/jp/cloud/free/#always-free

シェイプとして動的シェイプを選び、合計帯域幅の選択にマイクロを指定してロード・バランサを作成したところ、課金されました。

そのためロード・バランサを一旦削除して、異なるシェイプでロード・バランサを作成し直すことにしました。

シェイプをフレキシブル・シェイプにし、最小帯域幅の選択、最大帯域幅の選択を両方とも10Mbpsに変更して、ロード・バランサを作成しました。

Free Tierアカウント(アップグレードされていないアカウント)で作成できるロード・バランサは上記の設定に限定されています。

Free Tierアカウントでのロード・バランサのリソース制限を確認してみます。

ガバナンスの制限、割当ておよび使用状況を開きます。サービスとしてLBaaSを選択します。スコープにはホーム・リージョン、コンパートメントとしてルート・コンパートメントを選択します。

Free Tierアカウントでは、Flexible LB bandwidth total sumが10、Flexible Load Balancer Countが1に制限されていることがわかります。それ以外はすべて0です。

アップグレードされたアカウントを確認してみます。ガバナンスの制限、割当ておよび使用状況を開きます。サービス制限が緩和されています。

このサービス制限をAlways Freeに一致させます。

割当て制限ポリシーとして以下を設定します。ルート・コンパートメント名はそれぞれの環境に合わせて変更します。lb-flexible-bandwidth-sumは10、lb-flexible-countを1とし、それ以外は0にします。

Set load-balancer quota lb-10mbps-micro-count to 0 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-10mbps-count to 0 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-100mbps-count to 0 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-400mbps-count to 0 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-flexible-bandwidth-sum to 10 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-flexible-count to 1 in compartment [ルート・コンパートメント名]

ガバナンスの割当て制限ポリシーを開きます。割当て制限の作成をクリックします。

割当て制限ポリシーの作成として、名前はAlwaysFreeLBaaS、説明はAlways Freeの範囲内に制限とします。割当て制限ポリシーには前出の設定を、ルート・コンパートメント名を置き換えた上で記述します。割当て制限ポリシーの作成をクリックします。

割当て制限ポリシーが作成されます。

割当て制限ポリシーの画面に戻ります。

制限、割当ておよび使用状況を再度確認してみます。

Flexible LB bandwidth total sumの使用可能は10、Flexible Load Balancer Countは使用可能は1になっています。それ以外はすべて0で、割当て制限ポリシーにて指定した値になっていることが確認できます。

Always Freeの範囲で割当て制限をかけているため、ロード・バランサで課金が発生することは避けられます。Always Freeの範囲でロード・バランサを作成すると、制限、割当ておよび使用状況は以下のようになりました。

課金が発生した設定でロード・バランサを作成し、制限を確認してみます。ロード・バランサの作成画面で、動的シェイプのマイクロを選択します。

ロード・バランサのシェイプについてさらに学習するのリンクを開いて内容を確認すると、動的シェイプはwhich is only available to certain legacy customer accountsとなっており、利用に制限がかかっていること、You can also select the Always Free option if you have not used your one free tier accountとあり、アップグレードしたアカウントの場合はAlways Freeオプションを選択する必要がある（実際にはAlways Freeのオプションは無くなっています）と記載されています。

ロード・バランサの作成に必要な設定をすべて行い、最終的に送信するとlb-10mbps-countの制限を超えているので作成できない、とエラーが発生します。このシェイプはAlways Freeの対象ではないため、作成すると課金は発生します。Always Freeのオプションを選択していれば、lb-10mbps-micro-countのシェイプでロード・バランサが作成されたのだろうと予想されます。

最近、Oracle Cloudのアカウントを作成したユーザーには、そもそも動的シェイプが選択できないのかもしれません。動的シェイプが選択できる場合でも、選択しない方が良いように思います。コスト・エスティメータを使った予測の仕方が不明です。

今のところLoad Balancer Count(lb-flexible-count)が１、Flexible LB bandwidth total sum(lb-flexible-bandwidth-sum)が10の使用量で課金が発生していないことは確認していますが、お金に関することなので懸念がある場合は正式にベンダーに確認するのがよいでしょう。

完

GitHubにあるサンプル・アプリケーションの紹介 #JoelKallmanDay

 Oracle APEX 21.1より、サンプル・アプリケーションがGitHubから提供されるようになりました。

https://github.com/oracle/apex/tree/main/sample-apps

現在、１４のサンプル・アプリケーションが登録されています。これらのサンプル・アプリケーションはGitHubよりZIPもしくはSQLファイルをダウンロードし、使用中のワークスペースにインポートすることで利用できます。

これらのサンプル・アプリケーションに求めている実装が含まれているかどうかを、もう少し手早く確認できるようにするためapex.oracle.com上にインストールしました。

Oracle APEX情報サイトのコンテンツ一覧より、カテゴリGitHubにあるサンプルをチェックすると一覧されます。

https://apex.oracle.com/pls/apex/japancommunity/r/main/contents

サンプル・アプリケーションに与えるユーザー名、パスワードは任意の文字列で何でも構いません。

もともとサンプル・アプリケーションは、それぞれの環境にインポートして使用することが想定されています。データを更新すると、サンプル・アプリケーションの利用者全てに影響します。

ですので、データの編集作業を行うときは注意してください。他の方がデータの更新を行なっているかもしれない、という前提で操作をお願いします。自分自身は何の操作もしていないのに、レポートに表示される行が増減することがあり得ますし、プライベートな情報は入力しない、大量に行を削除したりしない、なども大切です。

ほとんどのサンプル・アプリケーションにはAdministrationのページがあり、そこにManage Sample Dataの項目が含まれます。

Manage Sample DataのページにはReset Dataのボタンがあります。データの更新も実施する場合は、こちらのReset Dataを行ってから作業することもできます。Reset Dataの実行もサンプル・アプリケーションを使用している他の利用者に影響があります。

以上、サンプル・アプリケーションの紹介でした。

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

完

APEXの標準ツール自体がAPEXのアプリケーションであることについて

 Oracle APEXの環境を管理する、例えばワークスペースを作成したり、ユーザーを登録したりするにはAPEXが提供している管理ツールを使います。また、アプリケーションを作成するには主にアプリケーション・ビルダーを使用します。

以前の記事に従って作成した環境を例にとって説明します。以下の作業を通常の開発作業で使用しているインスタンスで行うことはお勧めしません。

環境作成直後にAPEXにアクセスすると、以下の宛先にリダイレクトされます。

http://localhost:8080/ords/xepdb1/

URLの末尾がf?p=4550:1:となっています。Oracle APEXのURLの構造はマニュアルの

3.7 URL構文の理解

に解説のあるとおり、引数pの１番目がアプリケーションIDで、２番目がページ番号になります。つまり、上記の画面は、アプリケーションIDが4550のアプリケーションに含まれるページ番号１のページが表示されていることになります。

管理サービスへのサインインでは、アプリケーションID4550、ページ番号10が開きます。

新規ワークスペースの作成を案内するページは、アプリケーションID4050、ページ番号900です。

このように開発者によって作成されたアプリケーションと同じく、Oracle APEX標準の管理ツールもアプリケーションIDとページ番号を持っています。

Oracle APEXの開発ツールも同様です。アプリケーション・ビルダーの先頭画面は、アプリケーションIDが4500、ページ番号は1000です。

もっともよく使われているページ・デザイナーの画面はアプリケーションIDは4000、ページ番号は4500です。

Oracle APEXに組み込まれているアプリケーションは、APEXのインストールに使用するアーカイブのbuilderディレクトリ以下にSQLファイルとして保存されています。

$ ls 

de         f4020.sql  f4300.sql  f4500.sql  f4650.sql  f4850.sql  it  pt-br

es         f4050.sql  f4350.sql  f4550.sql  f4700.sql  f4900.sql  ja  zh-cn

f4000.sql  f4155.sql  f4411.sql  f4600.sql  f4750.sql  fr         ko  zh-tw

$ 

ページ・デザイナのページがどのように作られているのかを確認してみます。builder以下のf4000.sqlを手元にコピーします。このファイルは通常のアプリケーションと同じ手順で、ワークスペースにインポートすることができます。

インポートを実行します。

インポートするファイルとしてf4000.sqlを選択し、ファイル・タイプはデータベース・アプリケーション、ページまたはコンポーネントのエクスポートを選び、次に進みます。

確認画面が表示されます。次に進みます。ファイルサイズが大きい(20MB強)ため、少々時間がかかります。

アプリケーションのインストールをクリックします。次のアプリケーションとしてインストールはデフォルトの新規アプリケーションIDを自動割当てのままにします。アプリケーションID4000はOracle APEXをインストールした時点で使用されているので再利用することはできず、アプリケーションも置き換えることはできないので選択してはいけません。

1000ページ以上あるアプリケーションなので、インストールには時間がかかります。

アプリケーション・ビルダーが必要としているオブジェクトは作成済みであり、また、DBA権限がないとインストールできないものばかりです。サポートするオブジェクトのインストールは必ずOFFにして、次に進みます。

アプリケーションがインストールされました。APEXの管理ツールや開発ツールは特殊なアプリケーションなので、アプリケーションとして作成できても実行はできません。アプリケーションの編集を開いて、ページ・デザイナのページがどのような実装になっているかを確認します。

アプリケーションの編集をクリックします。

アプリケーション・ビルダー（のコピー）がアプリケーション・ビルダーで開かれます。

ページ・デザイナのページ番号は4500なので、4500番のページを探して開きます。

ページ・デザイナのページ（のコピー）がページ・デザイナで開かれます。

ページ・デザイナ自体がどのように実装されているのか、ページ・デザイナから確認することができます。

builder以下に含まれているOracle APEX標準のツールについては、このような手順で実装を確認することができます。

実際にはOracle APEXの開発ツールや管理ツールの実装を確認しなければならないケースは少ないでしょう。それでも、Oracle APEXの開発ツールや管理ツールもOracle APEXのアプリケーションである、と理解していると負荷の見積もりの助けになります。

アプリケーション・ビルダーやページ・デザイナを超えるほど複雑な画面構成のアプリケーションをユーザーが作成するケースはあまりないと思います。Oracle APEXのアプリケーションで発生する負荷はユーザーが定義したSQLまたはPL/SQLの実行(データ・ソースとして表を指定しても、それは実際にはSELECT * FROM 表の検索が行われます)と、その結果のレンダリング(HTMLのテンプレートに埋め込みHTMLページを生成する)になります。

Oracle APEXでアプリケーションの開発作業がそれほどストレスなく行えているのであれば、ユーザーのアプリケーションであっても、ページ・レンダリングのパフォーマンスに問題が発生する可能性は低いと想定できます。それ以外はSQLの実行にかかる時間なので、扱っているデータや、ユーザーが記述したSQL、PL/SQLのコードに依存する部分が大きくなります。

今回の記事は以上です。Oracle APEXのアプリケーション作成の参考になれば幸いです。

完

APEXのオペミスやコードの不具合で失ったデータを回復する

 Oracle APEXのSQLコマンドでは、実行をクリックするとコミットまでされます。

そのため、例えばwhere句をつけるつもりだったのに、うっかり以下のようなdelete文を実行してしまった、ということもあったりします。delete文を実行する表の名前を間違った、という場合もあり得ます。

delete from emp;

あわててrollbackを実行すると、以下のメッセージが返されます。

ロールバック文は適用されません。すべての文は自動的にコミットされます。

これが本番で使われているデータベースだったりすると、相当焦ります。

オラクルのデータベースでは、読取り一貫性を提供するために、変更前のデータがUNDO表領域に保存されています。このUNDO表領域に保存されている変更前のデータは、Flashback Queryを使って取り出すことができます。

通常のSELECT文にAS OF 時刻を付加します。例えば20分前の表EMPの情報を取り出し、表EMP_RECOVERに保存するには、以下のSQLを実行します。

create table emp_recover as

select * from emp as of timestamp (systimestamp - interval '20' minute);

指定する時刻はサーバー側の時刻です。データベースが日本時間ではなくUTCで動いている場合もあるため、時刻を指定する際にはあらかじめサーバー側のタイムゾーンを確認しておきます。確認方法は色々ありますが、SYSTIMESTAMPを表示させるのもひとつの方法です。

select systimestamp from dual;

to_timestampを使って時刻を指定し、変更前のデータを取り出します。

create table emp_recover2 as

select * from emp as of timestamp to_timestamp('2021/10/07 06:20:00','YYYY/MM/DD HH24:MI:SS');

今回の例のように全件消してしまった場合は、insert select文で回復できます。

insert into emp select * from emp_recover;

表にトリガーが設定されている場合、データの回復時に意図しない更新が発生することがあります。特に監査列(行の作成者、更新者、作成時刻、更新時刻を保存する列)の更新をトリガーで行っている場合は、データを回復する前にトリガーを無効化しておく必要があります。

オブジェクト・ブラウザを開き、データをリカバリする表を選択します。トリガーのタブを選択し、設定されているトリガーを確認し、無効化を行います。

トリガーであれば何でも無効化しないといけない、ということではありません。例えば主キーを設定するトリガーは、主キーとなる値の指定が無いときに限り自動的に主キーを生成する、というコードが一般的であるため、無効化する必要はありません。このようなトリガーを無効化するとデータの整合性に影響が出る可能性があるため、データの回復を阻害するトリガーのみを選んで無効化します。

例えば、サンプル・データセットの表EMPに設定されているトリガーEMP_TRG1のコードは以下なので、無効化は不要です。

create or replace trigger emp_trg1

before insert on emp

for each row

begin

if :new.empno is null then

select emp_seq.nextval into :new.empno from sys.dual;

end if;

end;

間違ってUPDATEをしてしまった場合の回復には、以下のようなUPDATE文が使えます。表EMPの全ての行の列SALを変更前の値に戻します。

update emp

set emp.sal =

(

select emp_recover.sal

from emp_recover

where emp_recover.empno = emp.empno

);

データを回復した後に、無効化したトリガーがあれば有効化しておきます。

どの程度まで遡って変更前のデータを回復できるかは、初期化パラメータのundo_retentionの設定とUNDO表領域の容量に依存します。

Autonomous Transaction Processingのインスタンスで確認したところ、900(秒)つまり１５分でした。UNDO表領域に余裕があればそれよりも以前の変更も保存されますが、データの回復はundo_retentionで指定された時間内で行うのがよいでしょう。

ちなみにAPEXのアプリケーションをエクスポートする際に指定できる、現在から〇〇分前も、フラッシュバック・テクノロジーを使っています。

アプリケーションのエクスポートには、パッケージDBMS_FLASHBACKが使用されています。DBMS_FLASHBACKは以下のような使い方になります。

begin

dbms_flashback.enable_at_time(

query_time => (systimestamp - interval '10' minute)

);

for r in (select * from emp)

loop

dbms_output.put_line(r.ename);

end loop;

dbms_flashback.disable;

end;

間違って表をドロップした場合には、FLASHBACK TABLEを使うことができます。初期化パラメータのrecyclebinがonであれば有効です。Autonomous Databaseでは、作成時に有効になっています。

 

例えばデータの回復が終了したので、表EMP_RECOVERをドロップしたとします。

drop table emp_recover;

まだ回復が必要なデータがあったとします。表EMP_RECOVERが必要です。まず、最初にビューUSER_RECYCLEBINを確認します。

select * from user_recyclebin;

リサイクルビン（つまりゴミ箱）に残っていれば、回復することができます。

表EMP_RECOVERを回復するために、以下のFLASHBACK TABLE文を実行します。

flashback table emp_recover to before drop;

SQLの実行が成功していれば、表EMP_RECOVERが回復されています。検索して確認してみます。

select * from emp_recover;

データが表示され、表EMP_RECOVERが回復されたことが確認できます。

表をドロップしてもリサイクルビンに残っていると、表領域の空き容量が増えません。物理的に削除し領域を再利用できるようにするには、リサイクルビンのパージを実行します。

再度、表EMP_RECOVERをドロップし、リサイクルビンの内容を確認します。

リサイクルビンのパージするために、以下のSQLを実行します。

purge recyclebin;

リサイクルビンを検索すると一行も表示されず、すべて削除されたことが確認できます。パージ後はFLASHBACK TABLE文を実行しても表を回復することはできません。

select * from user_recyclebin;

purge句を付けて表をドロップするとリサイクルビンに入らず、物理的に削除されます。表領域の空きを確保するために表をドロップする場合は、purge句を付けるのも良いでしょう。

drop table emp_recover purge;

Oracle APEXの開発で使用するワークスペースは複数の開発者が参加しています。リサイクルビンに残っている表はAPEXのアプリケーション開発者の誰がドロップしたのか分からない場合があり、また、その人が表を回復したいと思うことがあるかも分かりません。なので、リサイクルビンのパージ処理はワークスペースで開発作業を行っている人に確認してから実施した方が良いでしょう。

とにかく、オペミスなどをしてしまっても落ち着いて対応するのが一番大切です。

完