RDS for Oracleの検証結果と設計方針

QiitaのAWS初心者 Advent Calendar 2018 13日目

「Oracleじゃなきゃ、やだやだー、絶対やだー。PostgreSQLなんてものは、使ったこと無いし。むしろ、ポスグレなんてものは存在しなかった。」
という、プロジェクト備えてRDS for Oracleを検証した結果を紹介します。
※なお、計測結果については、日々変わる可能性があるため、あくまで、目安としてください。なお、当結果に基づいて被害が発生しても(以下略)

検証環境

・DB Client:Win 2016 + Oracle Instant Client 12.2.0.1.0
・DB Server:RDS for Oracle 12.2.0.1 SE Two License Included

検証結果

・db.t2.smallインスタンスの作成:20分
・インスタンスの削除:5分
・インスタンスサイズの拡大 (db2.t2.small ⇒ db2.t2.medium):5分
・インスタンスサイズの縮小 (db2.t2.medium ⇒ db2.t2.small):5分
・インスタンスの停止:10分
・インスタンスの起動:5分
・ディスクサイズの拡張(40GB->60GB) :5分*1
・ディスクサイズの縮小:NG
・EC2に導入したSQL*PlusからRDSへの接続:OK *2
・SQL*PlusからSQLを実行して日本語の表示:OK *3
・SQL*Plusを使ってPL*SQLの作成、実行:OK


結果は、無負荷実施時における、およその時間を掲載。トランザクション流しながら実施した場合、クラッシュリカバリなどの時間がかかるため、さらに時間がかかると思われる。
*1 インスタンス再起動後、バックグラウンドでStorage Optimizationが走る。20分程度実行していた。
*2 Instant Client 18.3.0.0.0は、Oracle DBへの接続完了後、「SP2-0310: ファイル"LOGIN.SQL"をオープンできません。」と出力される不具合(?)あり。
*3 クライアント側文字コードは、NLS_LANG=Japanese_japan.JA16SJISTILDEを使用。Japanese_Japan.AL32UTF8を使用すると、Plusの日本語出力が文字化けする。

検証結果を踏まえた設計方針

SoR向け。

ディスクサイズ

・拡張は、簡単に可能。ただし、縮小は不可能。よって、物理設計でざっくり見積もった初年度のサイズをもとに、構築する。あとは、毎年、必要に応じて拡張していく。
・RDSにおいてもディスクフルにすると、DBを停止させてしまうので監視は必須。

メモリやCPU

インスタンスタイプを変えることにより、簡単に大きくしたり、小さくしたりすることが可能。システムテスト時に初年度程度のデータ突っ込んで、インスタインスサイズ変えて、決めれば良いかと。

作者の気持ち

Auroraは、一見、良さげに見えるものの、きちんと運用するためには、Oracle DBやPostgreSQLをマスターしたときのように、内部動作の仕組みをきちんと理解しないと怖いかな。と。

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

hironobu_u

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。