10046 trace name context forever

前回 、COMMITの失敗時にトランザクションの成否は未確定で、タイミングによっては成功している場合もあるし、失敗している場合もあることを検証しました。 今回は、そのような不安定なトランザクションの状態を確認する方法としてOracle 12c R1からサポートされたトランザクションガードがどのようなものが確認してみます。 前回のCOMMIT問題のまとめ トランザクションガードの前提 トランザクションガードはOracle 12c R1以降でサポートされます。また、次に示す クライアント・ドライバをサポートしています。 12c JDBCタイプ4(Thin)ドライバ 12c OCI、OCCIクライアント・ドライバ 12c Oracle Data Provider for .NET (ODP.NET)、管理対象外ドライバ 12c ODP.NET、ODAC 12c リリース4以降の管理対象ドライバ 詳細は データベース開発ガイド を確認してください。 トランザクションガードを使うための準備 今回は、JDBC(Thin)ドライバを使ってトランザクションガードの動きを確認してみますがいくつか準備を実施します。 トランザクションガードに対応するサービスの作成(変更) 以下のようなSQLでサービスを作成しますが、COMMIT_OUTCOME=TRUEおよびRETENTION_TIMEOUTを適切なサイズにしてサービスを作成(変更)する必要があります。(以下はサービスを作成しています) DECLARE PARAMETER_ARRAY DBMS_SERVICE.SVC_PARAMETER_ARRAY; BEGIN PARAMETER_ARRAY('COMMIT_OUTCOME'):='true'; PARAMETER_ARRAY('RETENTION_TIMEOUT'):=604800; DBMS_SERVICE.CREATE_SERVICE( 'TX_GUARD','TX_GUARD',PARAMETER_ARRAY); DBMS_SERVICE.START_SERVICE('...

この記事は、 JPOUG Advent Calendar 2019  の22日目の記事です。 21日目はryota_hnkさんの 11gしか知らないオッサンが19cを触る でした。そして、なんと5年ぶりにJPOUG Advent Calendarで書くのですが(そもそも、このブログで何か書くのも5年ぶり...)、最近ちょっと考えてみた誰もが知っていて日常的に使っている「COMMIT」について書いてみたいと思います。 COMMITにおけるREDOログへの同期I/Oがパフォーマンス上問題になっている際によく観測される待機イベントは皆さんがご存知の"log file sync"になるのですが、ここでは深く触れません。"log file sync"について知りたい方は、以下、かなり昔にCOMMITにまつわるLog Writerの仕組みを書いたので参考にしてもらえると良いと思います。(ブラウザで見ると文字化けする部分があるのですが、ダウンロードするときれいに見えるとフィードバックをもらっています) Dbts2013 特濃jpoug log_file_sync from Koji Shinkubo COMMITの仕組みのおさらい 今回は、普段あまり気にしない(と思われる)COMMITの「失敗」や「成功」、さらにCOMMITの結果が「不明」といった状況について考えてみたいと思います。知っている人も多いと思いますが、念の為COMMITを実行した時の動き(若干デフォルメされ複数存在するlog writer workerはlg00と記載してます)を確認しておきます。 18c(12c以降)でのコミット時のシーケンス図 sqlplusなどクライアントは"COMMIT"という文字列をwrite(2)でServer Processのソケットに書き込みます "COMMIT"を受け取ったServer Processはsemctl(2)でlog writer(lgwr)を起床させます 起床したlog writer worker(lg00)はpwrite64(2)でオンラインREDOログにlog bufferの内容およびCOMMIT自体のchange vecto...

とうとう、 JPOUG Advent Calendar 2014 も最終日となりました。今年もご参加頂いた皆様に感謝しつつも、去年に続き、オオトリを務めさせていただきます。 Oracleデータベースも12.1.0.2というバージョンでIn-Memoryかつカラム型で分析系ワークロード用を高速化するオプションが導入されていることはご存じの通りです。 このIn-Memoryオプションという文脈で "ディスクは遅くメモリーは速い。だからIn-Memoryなデータベースは速い" とか "分析系ワークロードはカラム型といったデータフォーマット合っている。だからカラム型が速い" とか "データベースの処理をSIMD(シムディー)とかVector処理といった処理で行うと速い" とか なかなか、上記のキーワードがどのようにデータベース処理と関連しているか不明な状態で説明されることが多いのではないか。と思う今日この頃です。 今日は、In-Memoryやカラム型やSIMDといったキーワードを自分なりに関連あることとして、ここにメモ書きを残そうと思います。 言葉でアレコレ説明しても、よく分からん。(どなたかはSIMDの気持が知りたい。と仰っていた)なので、とてつもなくシンプルな疑似コードで説明してみたいと思います。 * ちなみに、以下示される疑似コードはOracleとも他のデータベースの作りとも全く関係ありません。目的は、疑似コードで処理のイメージを掴めれば良い程度の簡単なものです。(要はこんなにデータ構造はシンプルではないですし、コードもこんなに非汎用的ではないですし、正直、WHERE句のSIMD適用はこんなにお手軽ではないですし) 前提) 以下のような数十カラムを含むテーブル構成で1億件のランダムなデータが入っていると想定 SQLで書くと以下のような感じ create table large_table ( l_quantity number ,l_tax number ,... ,(沢山) ,... ); こんなテーブルをコードで書くと(とりあえずC)、以下のような構造体の配列(これは通常のロー型を想定)になると思います typedef stru...

I/Oリソース編 　これまで、マルチテナント・アーキテクチャにおけるCPUリソース、Memoryリソースの制御方法を考察してきたが最後にI/Oリソースの制御について考えてみる。 　Oracle Databaseは共有ディスクアーキテクチャーをとることから、従来からI/Oはボトルネックになりやすい重要なコンポーネントだった。マルチテナント・アーキテクチャにより、多くのインスタンスが集約されるとさらに、I/Oのリソース管理の重要性が増してくることは明らかである。 　さらに、初回のCPUリソース編でも述べたが、Database Resource ManagerではI/Oのリソース管理は提供されておらず(*1)I/Oリソース管理をするにはExadataによりI/O Resource Managerを使用する必要がある。 　筆者はExadataを検証環境として持ち合わせていないので、ここでExadata I/O Resource Managerの検証結果を記載できない。 　そこで、CPUリソース編で説明したOSネイティブなリソースマネージャ(*2)を使用したI/Oリソースの管理の方法を紹介したい。 (*1) Runaway SessionとしてのI/Oリソース管理は提供されている (*2) Linuxのcgroupsと初期化パラメーターPROCESSOR_GROUP_NAMEを使用する I/Oリソース制御としてPROCESSOR_GROUP_NAME 　初回のCPUリソース編で初期化パラメーターPROCESSOR_GROUP_NAMEを紹介したが、これはPROCESSORに限らずOSの持つcgroups(本件検証環境はOracle Linux 6.4 x86_64)の全ての機能を使用できる。 注意 cgroupsの機能をOracle Database 12 c がどこまでサポートしているか明確なドキュメントはなく、現時点は検証目的としてPROCESSOR_GROUP_NAMEでcgroupsのI/O制御を行っている事に注意 　まず、I/Oリソースに関して全く制御していない状況で、I/Oの速度を計測してみる。I/Oの速度計測にはOracleが提供しているDBMS_RESOURCE_MANAGE...

Memoryリソース編 　前回CPUリソース編として、Oracle Database 12 c のマルチテナント・アーキテクチャにおけるCPUリソースの制御の様子を検証してみた。今回は、Oracle Databaseで重要なコンポーネントであるSGA(System Global Area)を含むMemoryリソースの制御の様子を見てみたい。 　Oracle Databaseはインスタンス単位でSGAをもち、SGA内のコンポーネント(つまりMemoryリソース)の配分は、DBAが手動もしくは、Oracle Databaseによる自動管理で行うことが従来より可能であった。ここでのポイントは、Memoryリソースはインスタンス単位である点であり、プラガブル・データベース単位での制御はないということである。 　結論を先に書くと、Database Resource Managerや従来のDBAによる手動もしくはOracle Databaseによる自動によるMemory管理では、プラガブル・データベース毎にMemoryリソースを制御することは不可能である。 　本検証では、Memoryリソース管理が不可能である点を踏まえ、マルチテナント・アーキテクチャを考える際に注意しなければいけない(であろう)事を検証してみる。 　まず、マルチテナント・アーキテクチャにおけるSGAの仕組みを簡単に見てみる。 　この図から、SGAはコンテナ・データベースが管理し、プラガブル・データベース固有のSGAは存在しないことが分かる。 　さらに、重要なのは従来からSGAコンポーネントの中での鬼門であったSHARED POOLもコンテナ・データベースに1つしか存在しないという事をである。これは、1つのプラガブル・データベースでSHARED POOLの枯渇を誘発するような処理(例えばバインド変数を使用しないSQLが大量に実行されている等)により、他の問題のないプラガブル・データベースでエラー(ORA-4031など)が発生するといった悪影響に関する懸念が残る。 　今回は、このSHARED POOL、特にLIBRARY CACHE周りの動きを少し検証してみようと思う。 LIBRARY CACHE内のカーソルは誰のもの? 　SHARED POOL内のコ...

はじめに 　2013年のJPOUG Advent Calendarも今日で最後になりました。私のAdvent Calendarネタに関しては、若干、旬を過ぎた感は否めませんが、Oracle Database 12 c に関するものにしようと思います。 　実は、Oracle Database 12cリリース時に某メディアに寄稿予定だったものを(いろいろ事情があってお蔵入りになっていたもの)この場を借りて、全3回でお送りしようと思います。 Oracle Database 12 c  マルチテナント・アーキテクチャについて 　Oracle Database 12cの" c "がCloudを意味するようになり、プライベートやパブリックを問わずデータベースを集約して効率良くデータベースの集積率を高めるようなアーキテクチャを備えた今、" c "であるためのポイントは、集約した結果として物理的なリソースをどのように適切に配分するのか？また、物理的なリソースを適切に配分できるのか？ということに尽きると思う。 　物理的なリソースとはデータベースが使用するCPUリソース、Memoryリソース、I/Oリソースとなるが、細かいことを言えば、データベース内部のラッチなども挙げられる。 　O racle Database 12 c では、どのようなリソース管理が可能かについて検証していくつもりです。また、Oracle Database 12 c のマルチテナント・アーキテクチャで、データベースにおける各種リソースの管理方法が旧来のリリースから変更されており、合わせてOracle Database 12 c がどのようにリソースを管理しているかについても適宜、検証を行いたい。 　まず、簡単にマルチテナント・アーキテクチャをおさらいしておく。 　マルチテナント・アーキテクチャを簡単に理解すると、OSの持つリソースはコンテナ・データベースが管理し、プラガブル・データベースは、あたかも従来のスキーマのような振舞い(しかし、個別のデータベースとして隔離されて動作する)をしているように見える。 　プラガブル・データベースの追加は、スキーマ追加と同様にCPUやメモリーといった新たなリソースを確保する必要はな...

最初に 今日は、 JPOUG Advent Calendar のエントリです。 昨日の小田さんに続き、私は、 1μmも役には立たないエントリ となります ! 最近思うこと 昨今、データベースシステムを構成するハードウェアは大量のコア、一昔では考えられないほどの大量のメモリーが搭載し、さらにデータベースのボトルネックの王者たる風格さえ漂っていたI/Oにも高速化の波が押し寄せてきています。 そんな中、古くて新しい、そして、RDBMSとしての真価を問われるコンカレンシーの問題がボトルネックとして浮かび上がっているような気がしています。 このコンカレンシーの問題は、曲者で、どんなに高速なCPUを沢山搭載しても、どんなに沢山のメモリーを積んでも、ロケットばりの高速ストレージを使っても、コンカレンシーがボトルネックとなると全くパフォーマンスがスケールしません。(まぁー、極端な言い回しですが) そんな事を、つらつら考えつつ、コンカレンシーの問題が大きく関係するBuffer Cache上で繰り広げられる様々な動きを考えて見ることにします。 ここで、登場するボトルネックの原因となるWait Eventは、こんな物です。 latch: cache buffers chains latch: cache buffer lru chain free buffer waits read by other session まず、 SELECT文 のEXEC/FETCHフェーズを想像して下さい。 上記のWait Eventを噛み砕くと、こんな感じでしょうか? latch: cache buffers chains 「僕の探しているブロックはキャッシュされていますか～」を多くの人(Session)が聞きたがっている。でも、キャッシュされているか答えをもらうためのチケット(cache buffers chains latch)は一つ(もしくは非常に少ない)なので、なかなか、その順番が回ってこない。なので、「待つ」 * ちなみに latch: cache buffers chains は"聞く"だけなら、コンカレンシーの問題は起こらないのですが、このラッチは、「ブロックをキャッシュするので、ちゃんと管理してお...