渡部です。Oracle Database関連のレプリケーション技術について整理します。 Oracle Database本体のレプリケーション機能の多くが、サポートが終了していることに注意してください。 物理レプリケーションと論理レプリケーション データベースのレプリケーション技術は、物理レプリケーションと論理レプリケーションに大別されます。 物理レプリケーションは、データベース全体に対する物理的な更新を伝搬することで、 データベースを複製します。レプリケーション元のデータベース(プライマリDB)と レプリケーション先のデータベース(スタンバイDB)の物理的な構造が同じになります。 メカニズムがシンプルで運用しやすいため、災害対策に向けたDR構成/HA構成によく使用されます。 論理レプリケーションは、指定したテーブル群に対する論理的な更新を伝搬することで、 データベース内の指定したテーブル群
ストレージサーバにCell RAMキャッシュと呼ばれるキャッシュがある。Cell RAMキャッシュはフラッシュキャッシュの前面に位置し、フラッシュキャッシュよりレイテンシは低く、容量は小さい。そのため、cell single block physical readが上位にくるOLTPのワークロードにおいて、あたかもバッファキャッシュの追加キャッシュがストレージサーバ上にあることにより、オンライン性能向上が期待できる。ストレージサーバソフトウェア18cからの機能であり、デフォルトでは無効化されている(ramCacheModeがautoに設定されている)。 ストレージサーバのRAMキャッシュがデフォルトで無効なのは、なにも新機能なので自信がない訳ではない。これを有効に使うためにはストレージサーバ側のメモリの増設が前提となる。マニュアルを見ると、AWRのBuffer Pool Advisoryか
北陸コカ・コーラボトリングがOracle Exadata V1からX4への移行で「災害対策」「移行リスク最小化」のために取ったアプローチとは?:安全/確実なデータベース移行と災害対策のベストプラクティスを実践(3/3 ページ) Oracle Database 11g R2と12c R1の混在環境で移行リスクを軽減 Oracle Exadata X4-2への移行に際して渡辺氏らが特に検討を重ねたのは、「Oracle Databaseのどのバージョンを使うか」ということであった。 「Oracle Databaseを11g R2にするか、それとも12c R1にするかで何度も議論しましたが、結論を出す上で大きな決め手となったのは“サポートフェイズ”です。11g R2はPremier Supportが2015年1月に終了し、その3年後の2018年1月に延長サポートであるExtended Suppor
Amazon Web Services ブログ Oracle から PostgreSQL へ移行する際に、よく直面する課題を解決する方法 企業は年々データが急激に増加するのを目の当たりにしています。データベースとハードウェアインフラストラクチャをスケーリングし続けることは、ますます困難になっています。ワークロードが非リレーショナルデータストアに適していない場合に、基盤となるインフラストラクチャの管理に膨大な費用を費やすことなく、スケーリングの課題をどのように克服したらいいでしょうか? Amazon RDS for PostgreSQL と Amazon Aurora with PostgreSQL により、コスト効率の高い方法で PostgreSQL クラウドのデプロイを簡単にセットアップ、運用、拡張することができます。昨年、私たちは (数百 GB から数 TB に及ぶ) 100 を超える
MANABIYA ( https://manabiya.tech ) で話した資料です。
概要 Oracle 社の公式の Docker の設定ファイルが Github 上で公開されています。 github.com 設定ファイルには様々な製品の物が含まれていますが、今回はこれを使用して Oracle Java の実行環境を構築します。 作業 設定ファイルと Java のサーバランタイムをダウンロードします。次にサーバランタイムを適切な箇所に移動して、Docker イメージを作成します。最後に作成したイメージで Java が使えるか確認します。 Github から docker-images を落とします。git コマンドでも良いですし、ブラウザからZIPファイルをダウンロードも出来ます。docker-images のディレクトリを移行は IMAGES_HOME とします。 Java のサーバランタイムを次のリンクからダウンロードします。 http://www.oracle.com
1. 初めにDBにおける処理はSQLによって記述しますが、データの取得するために具体的にどのような内部処理を行うかという点までは記述しません。 ここでいう内部処理とは「SQLの書き換え」「インデックスの使用」「結合アルゴリズムの選択」などがDBMSのオプティマイザによって選択されて実施されることを指します。 SQLのパフォーマンスを見るにあたっては上記の内部処理について正しく理解する必要があります。 本Blogでは、重要なアルゴリズムであるにもかかわらず、まとまった情報が少ないSQL実行時におけるブルームフィルタ(Bloom Filter)についてOracleをもとに紹介を行います。 Bloom Filterは結合処理を効率化するために、結合の前段階で利用される技術になります。 公式なドキュメントとしては以下になります。 Oracle Database SQLチューニング・ガイド 12cリ
Hatem Mahmoud's blog Just another blog : Databases, Linux and other stuffs Using FlameGaphs for investigating performance problem can be a valuable asset for quick resolution and identification of the root cause. This type of analysis may be needed when the traditional oracle instrumentation are not enough. This post is based and inspired by the awesome work of Brendan Gregg ,Luca Canali and Fri
固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6- 2016/2/23(火) に 開催された JPOUG Tech Talk Night #6 で 語った、 Oracle Database の オプティマイザ統計運用 についてのスライドやで 彡(゚)(゚) JPOUG Tech Talk Night #6 固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 - 柴田 歩 - http://www.jpoug.org/2016/01/21/ttn6 2/23(火) の JPOUG Tech Talk Night #6 で Oracle Database の オプティマイザ統計運用 について語ります。 http://d.hatena.ne.jp/gonsuke777/20160121/1453342953 キーワード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く