[アップデート] Amazon RDS for Oracleのマルチテナント構成でAWS Secrets Managerを使ったクレデンシャル管理がサポートされました | DevelopersIO

AWS BackupにてRDS for Oracleのスナップショットをクロスリージョンコピーした際にエラーが出たので調査してみた | DevelopersIO

[アップデート] Amazon RDS for Oracle 19c に Spatial Patch Bundle (SPB) が提供されるようになりました | DevelopersIO

RDS for Oracle マテリアライズドビューのリフレッシュ関連のオプションを調べてみた | DevelopersIO

下記のブログではOracle DBをマテリアライズドビューを利用してデータを移行する方法をまとめました。 しかし、前回のブログの方法では移行先のデータベースに差分ができたら、手動コマンドを実行して最新状態に更新する必要がありました。 マテリアライズドビューには差分を自動で更新できることを含めていろんな設定があります。 本ブログではマテリアライズドビューのリフレッシュと関連があるオプションをまとめました。 リフレッシュ以外の他オプションの説明は下記のページをご参考ください。（Oracle Database 19） AS SELECT文 AS SELECT文のみ作成すると、全ての設定がデフォルトになっているマテリアライズドビューを作成します。 リフレッシュとは関係ないですが、ここにオプションを追加して行きます。 AS : マテリアライズド・ビューを定義するクエリを指定 実行結果がマテリアライズド・ビューに格納されて、有効なクエリーである必要がある 例 本ブログではマテリアライズドビューを作成するまでの手順はスキップします。（全ての手順は下のブログの手順3までは省略します。） 下記のようにデータベースリンクを利用して他のデータベースにあるテーブルのデータを持ってくるのもできます。 ※ remote_site：データベースリンク名 もし、同じデータベースが元になるマテリアライズドビューを作成したい時には下記のように実行します。 BUILD {IMMEDIATE | DEFERRED} BUILD {IMMEDIATE | DEFERRED} : マテリアライズドビューにいつデータを入れるかを決定 IMMEDIATE デフォルト マテリアライズドビューの作成と一緒にデータを入れます。 DEFERRED マテリアライズドビューを作成する時にデータを入れません。 データを入れるためには別途のコマンド実行が必要 例（IMMEDIATE、DEFERRED） IMMEDIATEはマテリアライズドビューを作成するタイミングにデータを入れるので、ビューを作成した後に確認してみるとデータが入っています。 DEFERREDで設定ですると、ビューを作成する時にデータを入れないです。 REFRESH {FAST | COMPLETE | FORCE} REFRESH : 送信元のテーブルとの差分が発生した時にその内容を更新する作業 FAST 移行元のデータベースにマテリアライズドビューログが必要。（MLOG$[table_name]・RUPD$[table_name]） ログから更新レコード情報を確認して増分方式でデータをリフレッシュ 差分だけ更新するので、処理速度が早く 一部のテーブルに対して制限事項がある FASTリフレッシュの制限事項 COMPLETE 既存のデータを削除して、送信元デーブルの全体のデータを再読み込んで更新する方法 マテリアライズドビューログは必要ない FORCE デフォルト まずはFASTでリフレッシュを実行して、実行できない場合はCOMPLETE実行するオプション 例（FAST、リフレッシュの手動実施する方法） FAST設定 COMPLETE と　FORCE　をする時にはログの設定はしなくても構いません。（FORCE にログがないと、FASTは失敗してCOMPLETEで実行する） 手動実施する方法もあります。 ON {COMMIT | DEMAND | STATEMENT} ON {COMMIT | DEMAND | STATEMENT} : リフレッシュのトリガー設定 COMMIT 元テーブルのトランザクションがコミットされたデータの変更によってリフレッシュを実行 リモートテーブル（他DBにあるテーブル）を使用するマテリアライズド・ビューではサポート不可 ON COMMITのリフレッシュの制限事項 DEMAND デフォルト 手動や予約されたタスクによってリフレッシュを実行 STATEMENT DML操作が実行される時にリフレッシュする マテリアライズド・ビューを作成するタイミングに作成して、その後は変更不可 REFRESH FASTと一緒に設定する必要ある ON STATEMENTのリフレッシュの制限事項 例（COMMIT） COMMIT設定をするためには同じデータベースにあるテーブルを元に作成できます。 作成すると、元のテーブルでトランザクションがCommitがある場合に自動的にリフレッシュします。 START WITH {日時式} / NEXT {日時式} ON DEMANDを指定している場合のみ設定可能で、START WITH・NEXTを指定すると、ON …

Amazon RDS for OracleのS3統合(S3_INTEGRATION)の通信はどこを通っているのか | DevelopersIO

初めに Amazon RDS for OracleではS3統合(S3_INTEGRATION)を利用することでS3バケットと通信をしデータをやりとりすることが可能です。 設定も非常に手軽でオプショングループでS3_INTEGRATIONを有効化、IAMロールもしくはバケットポリシーに必要な権限を割り当てた上でS3統合で利用するIAMロールをRDSに割り当てるだけです。 そう、たったこれだけで良いのです。例えインスタンスがプライベートサブネット上かつNAT GatewayやVPCエンドポイントが用意されていなくともS3バケットとやりとりができます。 特にVPCエンドポイントが不要な点は先のURLに明記されています。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/oracle-s3-integration.html DB インスタンスが Amazon S3 バケットにアクセスできる必要があります。DB インスタンスで使用される Amazon VPC は Amazon S3 エンドポイントへのアクセスを提供する必要はありません。 …いったいどうやってAmazon S3と通信しているのでしょうか。 ログを見てみる 以下の2つの情報を確認してみます VPCフローログにおけるRDSインスタンスのIPをソースとする宛先443番ポートの通信 少なくともS3にアップロードするためにどこかとは通信してるはず Amazon S3宛であればS3のAPI(HTTPS)を呼んでいるはず 宛先S3バケットで発生したデータイベント 終端となる部分のログを見ることで少なくともその直前の通信は確認可能 いずれも別途取得の設定が必要ですが具体的な設定方法はここではは割愛します。データイベントに関するログははCloudTrailはデフォルトでは取得しないため忘れがちではあるので注意しましょう。 データアップロードは以下を参考に実施しました(Oracle DB何もわからない…)。 VPCフローログ S3に通信しているのであればAWS APIはHTTPSによる通信となるためひとまずそちらで絞り込みをかけてみましょう(+大体の実行時刻で絞り込みかけてます)。 RDSのIPは192.168.2.30、サブネットの指定的に192.168.2.0/24(もしくはもう片側のAZの192.168.1.0/24)に所属するはずなのでこの辺りから出ているはずなのですが..見当たりません。 他に見えているIPも検証時に起動しているEC2のものとなります。 もう少し広げて該当VPC全体(192.168.0.0/16)をソースとして調べてみましたが何か別のもので出ているということもなく、RDSからの通信はSQLを実行するためのEC2間との接続のみとなりました。 つまりのところRDS上のストレージのデータの取り出しはVPC内から行われていないようです。 データイベント アップロードした際のデータイベントを抽出したところ以下のようなイベントが取得できました。 invokedByの値がrds.amazonaws.comなので別のサービスを経由しているということもなくあくまでRDSが実行したという形になりそうです。 https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/how-cloudtrail-works.html CloudTrail ユーザーが直接行ったアクション、またはユーザーに代わってサービスが行ったアクションをキャプチャします。 AWS たとえば、 AWS CloudFormation CreateStack呼び出しによって、Amazon EC2、Amazon RDS、Amazon EBS、またはテンプレートで要求されるその他のサービスへの追加の AWS CloudFormation API 呼び出しが発生する可能性があります。この動作は正常であり、想定されています。 AWS アクションがサービスによって実行されたかどうかは、invokedbyイベントのフィールドで確認できます。 結局のところ 詳細については公開情報がなく曖昧な情報となっているのですが、VPC外部の通信ではあるものの(VPCフローログに出力なし)、AWSサービス間の通信で完結している(S3のデータイベントより)と見ることができます。 冷静に考えるとRDSのログのCloudWatch Logsへの出力も同様にVPCエンドポイントやインターネットへの経路がなくとも通信できるため、推測とはなりますが処理の起点自体はインスタンスの中とはなるものの取り出しの仕組みについてはこれと似たようなところがあるのかもしれません。 https://aws.amazon.com/jp/vpc/faqs/?nc1=h_ls 2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか? いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。 さらに、データセンターとリージョンを相互接続する AWS グローバルネットワークを流れるすべてのデータは、安全性が保証された施設を離れる前に、物理レイヤーで自動的に暗号化されます。すべての VPC クロスリージョンピアリングトラフィックや、カスタマーまたはサービス間のトランスポート層セキュリティ (TLS) 接続などといった追加の暗号化レイヤーもあります。 いずれにしてもAWSでホストされているシステムに関しては仮にパブリックIPが付与されていたとしてもAWS管理ネットワークを通る仕様となっておりますのでとなっており、RDS・S3間のサービス間通信となる今回も同様に少なくともインターネットを通らずAWS管理ネットワークで完結する形となります。 またS3への通信自体に関してもAWS APIで実行されていますが(“eventType”: “AwsApiCall”)、AWS APIは現状最低TLSv1.2以上のHTTPS通信が必須要件となっている関係で通信の暗号化強度も一定は保証されております。 終わりに ユーザ側から見れるログ部分としては情報が少なく検証としてはやや消化不良感のあるような形にはなってしまいましたが、VPC内部にあるリソースではあるものの一種のマネージドサービス(機能)と捉えるとユーザの関与する部分ではないものですし少し納得のいくような感じはします。 経路としてはインターネットに出るようなことはなく、一定強度以上の暗号強度もは保証されているので基本的には安心してご利用いただいて良いところとはなりそうです(求められる要件は環境により異なるため必ずではない)。 どうしても個人情報が直接含まれる部分のでもう少し経路を明確にしつつでも外部ストレージ間とインポート・エクスポートを…となると現時点では19c限定とはなりますがEFS統合を一つの選択肢として考えても良さそうです。

Oracle マテリアライズドビューを使用してデータを移行をしてみた | DevelopersIO

本ブログではOracle DBをマテリアライズドビューを利用してデータを移行する方法をまとめました。 移行方法は下記のページを参考しています。 Oracle マテリアライズドビューを使用した移行 アジェンダ 検証環境の作 …

Amazon RDS for Oracle에서 초기 데이터베이스에 추가한 테이블이 스냅샷을 통해 초기 데이터베이스 이름을 변경해도 유지될까? | DevelopersIO

Amazon RDS for Oracle에서 초기 데이터베이스에 추가한 테이블이 스냅샷을 통해 초기 데이터베이스 이름을 변경해도 유지되는지 확인해 봤습니다.