Oracle Cloud Infrastructure Blog(翻訳)

Oracle Database 19c のダイナミック CPU スケーリング (2020/05/25) https://blogs.oracle.com/database/post/dynamic-cpu-scaling-in-oracle-database-19c 投稿者： Christian Craft Oracle Database 19c のダイナミック CPU スケーリング   Oracle Database 19c（リリース19.4以降）には、CPUの最小値/最大値の範囲を使用して、ワークロードの要求に応じてPluggable Databaseのコンピュートを動的にスケールアップ/スケールダウンする機能が搭載されています。 Pluggable Databaseで利用可能なコンピュートリソースのスケールアップとスケールダウンは、介入なしで自動的に、瞬時に、かつダイナミックに行われるように構成できます。 なぜこれが重要なのか？すべてのシステム（ベアメタル、仮想マシンを問わず）には、ある時点で未使用のコンピュートキャパシティがあります。 データベースのワークロードは一定ではなく、1日の中で大きく変化する可能性があります。ダイナミックCPUスケーリングにより、プラガブルデータベースは、システムに空き容量があれば、必要なときに自動的に余分な容量を消費します。この機能により、システムレベルでのオーバープロビジョニングの必要性がなくなり、未使用のコンピュートキャパシティを活用しながら、より予測可能なパフォーマンスが得られます。クラウドのサブスクリプションモデルで稼働しているデータベースの場合、ダイナミック CPU スケーリングはプロビジョニングされた容量をより効果的に使用するため、サブスクリプションコストを削減できます。 ノイジーネイバーの問題に対するより良いアプローチ この新機能が導入される前は、DBA はデータベースのピーク負荷に合わせてリソースを割り当て、確実にスケールアップできるようにしたり、必要なリソースが他のアプリケーションに取られないようにしなければなりませんでした。Oracle Database 19.4 の min/max レンジを使用する機能は、制御が困難で深刻なパフォーマンス問題を引き起こす可能性のあるオーバープロビジョニングに依存しない...

サーバーレス・ファンクションのためのホットなデータベース接続 (2020/05/24) https://medium.com/oracledevs/hot-database-connections-for-serverless-functions-9f9e8a681df6 投稿者： Kuassi Mensah 図: Autonomous Database（ATP-S）インスタンスに接続するOracle Functionインスタンス 前置き - 解決すべき課題 新しいサーバーレスコンテナの起動（コールドスタート）には、1秒から数秒かかる（時間はプラットフォームによって異なる）。このようなコスト・レイテンシーをなくすために、サーバーレスフレームワークでは、すでに起動したコンテナを一定期間温めておく（期間はプロバイダーによって異なる）。 サーバーレス・ファンクションでデータベースにアクセスすることがある。新規にサーバーレスコンテナを起動するよりはコストが低いものの、DBMS環境によっては、データベース接続の作成と削除に数十ミリ秒から数百ミリ秒のコストがかかる場合があります。この問題は、毎回の呼び出しにそのようなコストをかけられない短命なサーバーレス・ファンクションでは悪化します。 解決すべき最初の問題は、接続の作成と切断を避けることです。 接続をコンテナ間でプール/共有できないため、解決すべきもう1つの問題は、固定のデータベース接続数を前にして、自動スケーリングと何千ものサーバーレス・ファンクションの同時呼び出しという高い同時性の影響です。 この記事の議論、解決策、ベストプラクティスは、Javaをベースにしていますが、サーバーレスインフラストラクチャがサポートするすべての言語に適用できます（例えば、Oracle Functionsは、Java、Go、Node.js、Python、Rubyをサポートしています）。 コネクションの作成と削除の回避 既存の接続を再利用するのにかかる時間は数ミリ秒以下ですが、サーバーレス・ファンクションの各インスタンスは、単一のデータベース接続を持つ個別のコンテナで実行されるため、これらの接続をプールしてコンテナ間で共有することはできません。 幸いなことに、サーバーレスのコンテナは、ファンクションの呼び出しが終了すると数分間保持されます。さらに、...

Always On 可用性グループを使用したOCI-ClassicからOracle Cloud InfrastructureへのSQL Serverの移行 (2020/05/21) https://blogs.oracle.com/cloud-infrastructure/migrating-sql-server-from-oci-classic-to-oracle-cloud-infrastructure-with-always-on-availability-groups 投稿者： John Parker | Cloud Solution Architect この移行戦略の目的は、SQL Server データベースまたは SQL Server データベースの論理グループをわずかなダウンタイムで移行できるようにすることです。 この戦略では、Microsoft SQL Server with Always On 可用性グループを使用して、 現在 Oracle Cloud Infrastructure-Classic（OCI-Classic）環境にある重要な SQL Server リソースを Oracle Cloud Infrastructure に移行します。 この同じ戦略は、他のクラウドやオンプレミスのデータセンターからも適用できます。 アーキテクチャは次の図のようになります。 この戦略の基本は、SQL Server Always On 可用性グループを使用して、 ミッションクリティカルなデータベースや大きすぎて移行に割り当てられた現在のダウンタイムに収まらないデータベースを移動させることです。 OCI-Classic リージョンと Oracle Cloud Infrastructure リージョンに存在する 2 つ以上の SQL Server データベースの間に、Always On 可用性グループを構築します。 SQL Server Always On 可用性グループは、1 つの可用性グループ内で 1 つ以上のデータベースを処理するため、 データベースのダウンタイムを最小限に抑えながら、データベースの最適な移行を容易にする論理的な方法で可用性グループを構築してください。 この戦略は、移行の5つのフェーズを使用しています。「発見」「分析」「計画」「移行」「移行後」...