2018年8月19日 (日)

FAQ::位置情報による時間帯の自動調整 - iPhone/Apple Watch/iPad/Mac

ひさびさのエントリーでございます。

試用期間終わり、ひとまず生き延びておりますw

そして、早々に海外かつ人生はつの海外出張ということで、
Mac De Oracleの中の人として、ここは声を大きくして言っておきたいw

MacとiPhoneとApple Watchって

”国を跨いでも現地時間に自動調整してくれちゃうのは超便利!”

iPhone/Apple Watchを持ってる方は大抵 時間の自動調整はオンになっている方は多いかなーとは思いますが、意外に忘れてたりするのがMac側だったりします。

ということで、FAQとして書いておきますね。

続きを読む "FAQ::位置情報による時間帯の自動調整 - iPhone/Apple Watch/iPad/Mac"

| | コメント (0) | トラックバック (0)

2018年7月11日 (水)

Swift4 はじめました

Swiftが登場してから随分経ちますが、こどもと Swift Playgroundsであそんだ程度だし、
自分も新しいワールドに突撃したばかりなので。。。このネタは続けるか、微妙な感じはしてますが。

間が空いちゃいました、お久しぶりでございます。

まだまだ、新しい環境で慣らし運転の身なのでペースは上がらないとおもいますので、そこんのところよろしくお願いしますw (^^;;

脳が疲れてw 早寝したのに、暑さで目覚めてしまったこともあり、
折角なので、Swiftを使ってsarの結果をcsv化してみた。csv化後はExcelのPivotを使ってグラフを作ると。。。、気分転換も兼ねてw

Swift初期版しか触ってないのに(書きたい気持ちはあったのですが、なかなかさわれてなかった。。。)、ということでSwift4でも遊べたらいいなぁ。と思いつつ、こんなときじゃないとやる暇なさげな感じもw
(Swift4の作法としてそれいいの?などもいろいろあろうかと思いますが、ここをこう変えたほうがいいかもよ。などございましたら、ご指摘していただけるとうれしいです。)


調べてたら、Swiftってこんな使い方もできるのね。という気づきもあり:)

Swiftのバージョンは以下のとおり。

discus-mother:˜ oracle$ swift -version
Apple Swift version 4.1.2 (swiftlang-902.0.54 clang-902.0.39.2)
Target: x86_64-apple-darwin17.6.0
discus-mother:˜ oracle$

今回使ったインプットは、先日ネタで取り上げてグラフまで貼り付けてたsarの結果です。
前回、Oracle Database Connect 2018 エキスパートはどう考えるか? 体感!パフォーマンスチューニング Ⅱ (番外編=没ネタ)で使ったCPU使用率グラフ。

内容は以下のとおり。

[muser@localhost ˜]# sar 5 10000 

Linux 4.1.12-94.3.6.el7uek.x86_64 (localhost.localdomain) 04/25/2018 _x86_64_ (12 CPU)

12:59:39 AM CPU %user %nice %system %iowait %steal %idle
12:59:44 AM all 0.82 0.00 0.15 0.00 0.00 99.03
12:59:49 AM all 1.87 0.00 0.39 0.02 0.00 97.73
12:59:54 AM all 3.13 0.00 0.64 0.34 0.00 95.89
12:59:59 AM all 1.23 0.00 0.42 0.44 0.00 97.91

・・・中略・・・

01:02:34 AM all 6.66 0.00 0.48 0.29 0.00 92.57
01:02:39 AM all 6.51 0.00 0.51 0.31 0.00 92.67
01:02:44 AM all 6.88 0.00 0.48 0.34 0.00 92.30
01:02:49 AM all 6.71 0.00 0.53 0.36 0.00 92.40

01:02:49 AM CPU %user %nice %system %iowait %steal %idle
01:02:54 AM all 6.69 0.00 0.55 0.31 0.00 92.46
01:02:59 AM all 6.38 0.00 0.63 0.24 0.00 92.75
01:03:04 AM all 6.61 0.00 0.58 0.32 0.00 92.48

・・・中略・・・

01:05:44 AM all 6.29 0.00 0.53 0.26 0.00 92.92
01:05:49 AM all 6.41 0.00 0.58 0.36 0.00 92.64
01:05:54 AM all 6.39 0.00 0.53 0.26 0.00 92.83
01:05:59 AM all 6.72 0.00 0.65 0.38 0.00 92.25

01:05:59 AM CPU %user %nice %system %iowait %steal %idle
01:06:04 AM all 6.61 0.00 0.55 0.32 0.00 92.51
01:06:09 AM all 6.95 0.00 0.58 0.48 0.00 91.99

・・・中略・・・

01:08:54 AM all 6.80 0.00 0.48 0.39 0.00 92.33
01:08:59 AM all 6.15 0.00 0.55 0.33 0.00 92.98
01:09:04 AM all 5.98 0.00 0.60 0.43 0.00 92.98
01:09:09 AM all 6.06 0.00 0.50 0.24 0.00 93.20

01:09:09 AM CPU %user %nice %system %iowait %steal %idle
01:09:14 AM all 6.51 0.00 0.57 0.48 0.00 92.44
01:09:19 AM all 6.55 0.00 0.50 0.21 0.00 92.75
01:09:24 AM all 6.62 0.00 0.56 0.38 0.00 92.44

・・・中略・・・

01:12:04 AM all 6.63 0.00 0.51 0.44 0.00 92.41
01:12:09 AM all 6.78 0.00 0.44 0.34 0.00 92.43
01:12:14 AM all 6.68 0.00 0.48 0.38 0.00 92.47
01:12:19 AM all 6.83 0.00 0.58 0.39 0.00 92.20

01:18:39 AM CPU %user %nice %system %iowait %steal %idle
01:18:44 AM all 7.08 0.00 0.61 0.41 0.00 91.90
01:18:49 AM all 6.79 0.00 0.53 0.34 0.00 92.34

・・・中略・・・

01:19:39 AM all 0.49 0.00 0.08 0.03 0.00 99.40
01:19:44 AM all 0.42 0.00 0.07 0.00 0.00 99.51
01:19:49 AM all 0.05 0.00 0.03 0.00 0.00 99.92
01:19:54 AM all 0.05 0.00 0.02 0.00 0.00 99.93
01:19:59 AM all 0.59 0.00 0.15 0.02 0.00 99.24


sarで取得したcpu使用率のログファイルを Swfitを使ってcsv変換しました。

discus-mother oracle$ 
discus-mother oracle$ chmod u+x sar2csv.swift
discus-mother oracle$ ll
total 408
-rwxr--r--@ 1 oracle staff 1413 5 1 18:50 sar2csv.swift
-rw-r--r--@ 1 oracle staff 10253 5 1 19:11 sar_production.csv
-rw-r--r--@ 1 oracle staff 30169 4 30 19:46 sar_production.log
-rw-r--r--@ 1 oracle staff 75418 5 1 19:46 sar_production.xlsx
-rw-r--r--@ 1 oracle staff 20176 5 1 19:37 sar_test.log
discus-mother oracle$
discus-mother oracle$ ./sar2csv.swift sar_test.log
Processing sar_test.log to sar_test.csv....
11526bytes written
discus-mother oracle$ ll
total 432
-rwxr--r--@ 1 oracle staff 1413 5 1 18:50 sar2csv.swift
-rw-r--r--@ 1 oracle staff 10253 5 1 19:11 sar_production.csv
-rw-r--r--@ 1 oracle staff 30169 4 30 19:46 sar_production.log
-rw-r--r--@ 1 oracle staff 75418 5 1 19:46 sar_production.xlsx
-rw-r--r-- 1 oracle staff 11526 6 26 23:45 sar_test.csv
-rw-r--r--@ 1 oracle staff 20176 5 1 19:37 sar_test.log
discus-mother oracle$

csv化した結果は以下のとおり

discus-mother oracle$ cat sar_test.csv

12:59:39,AM,CPU,%user,%nice,%system,%iowait,%steal,%idle
12:59:44,AM,all,0.82,0.00,0.15,0.00,0.00,99.03
12:59:49,AM,all,1.87,0.00,0.39,0.02,0.00,97.73
12:59:54,AM,all,3.13,0.00,0.64,0.34,0.00,95.89
12:59:59,AM,all,1.23,0.00,0.42,0.44,0.00,97.91
01:00:04,AM,all,6.33,0.00,1.13,0.17,0.00,92.37
01:00:09,AM,all,6.38,0.00,0.53,0.15,0.00,92.93

・・・中略・・・

01:19:29,AM,all,6.95,0.00,0.48,0.43,0.00,92.15
01:19:34,AM,all,5.31,0.00,0.39,0.24,0.00,94.06
01:19:39,AM,all,0.49,0.00,0.08,0.03,0.00,99.40
01:19:44,AM,all,0.42,0.00,0.07,0.00,0.00,99.51
01:19:49,AM,all,0.05,0.00,0.03,0.00,0.00,99.92
01:19:54,AM,all,0.05,0.00,0.02,0.00,0.00,99.93
01:19:59,AM,all,0.59,0.00,0.15,0.02,0.00,99.24

続きを読む "Swift4 はじめました"

| | コメント (0) | トラックバック (0)

2018年5月 2日 (水)

Oracle Database Connect 2018 エキスパートはどう考えるか? 体感!パフォーマンスチューニング Ⅱ (番外編=没ネタ)

Oracle Database Connect 2018 エキスパートはどう考えるか?体感!パフォーマンスチューニング Ⅱ
~Autonomous Databaseの到来において必要となるチューニングとは~

これ、パフォーマンスチューニングネタをまとめ上げるまで、みなさんスケジュール調整し、
オンライン/オフラインミーティングを繰り返してネタを詰めていくという、かなーり面倒なことをやっています。
私なんて、ネタの候補検討だけで16時間ぐらい使ってますからねw(自分の余暇を使って、半分楽しみながら、締め切りがあるので半分苦しみながらw)


余談はこれくらいにして、今日の本題です。:)

Oracle Database Connect 2018 エキスパートはどう考えるか? 体感!パフォーマンスチューニング Ⅱ で没にしたネタがあるのですが、
そのまま捨てるのも勿体ないので、多少取得情報を追加した状態で公開しちゃおうと思います。


続きを読む "Oracle Database Connect 2018 エキスパートはどう考えるか? 体感!パフォーマンスチューニング Ⅱ (番外編=没ネタ)"

| | コメント (0) | トラックバック (0)

2018年5月 1日 (火)

Oracle Database入学式 2018 – 保護者の方はご遠慮ください

入学式にしては少々、遅めですがw 今年もOracle Database入学式 2018 行います。

講師は、Oracle ACE 渡部 亮太 氏です。

詳細は以下をご覧ください。 ↓↓↓↓↓↓↓↓↓↓↓↓
Oracle Database入学式 2018 – 保護者の方はご遠慮ください

| | コメント (0) | トラックバック (0)

2018年4月18日 (水)

Dead Connection Detection (FAQ)

最近あまりお目にかかったことなく忘れかけてたのと、12cでは改善されてたのでメモ

12cだと、11g以前に比べ、Dead Connection Detection (DCD) までの時間が大幅に短縮されているよ。
というホワイトペーパー

Dead Connection Detection
http://www.oracle.com/technetwork/database/enterprise-edition/oraclenetdcd-2179641.pdf

| | コメント (0) | トラックバック (0)

2018年4月 8日 (日)

textフォーマットのAWRレポートの各セクションをcsvファイル化する際のポイント(メモ)

土日は土日で子供とマイクラのマルチプレイ、平日は平日でなんだか余裕ないぞー。(なんだこれw) ということで、
Temp落ちネタはFBのTLコピペすれば終わりそうなんだが。。。w
再び、別のネタ。気分転換にはなってないけどwww


textフォーマットのAWRレポートをcsvファイル化する際、各セクションの最終行判定が面倒だったのでメモ(12.2版)
(どんな言語で作ってもこの部分、レポートの文字コード、それに、日付書式でハマることが多い印象w、それに、12.2では、 Timeはsecのみではなく、us/msなど時間の単位の扱いが追加されたので変換を忘れるとハマる)

例えば、Top 10 Foreground Events by Total Wait Timeの場合、
"Top 10 Foreground Events by Total Wait Time"というセクションヘッダーから、次のセクションヘッダーの"Wait Classes by Total Wait Time"の直前の行までを、Top 10 Wait Eventとしてcsv化する。

この場合、”Wait Classes by Total Wait Time”の直前の行は、2バイトで<FF><LF>なので、<FF><LF>の行が"Top 10 Foreground Events by Total Wait Time"セクションの終わり。

なのだが、"Top 10 Foreground Events by Total Wait Time"セクションの直前の行は、1バイトで<LF>のみとなり、 <FF>を含まないケースもある.....
各セクションの最終行の判定は、2バイトで<FF><LF>または、1バイトで<LF> で判定する必要がある。と。

続きを読む "textフォーマットのAWRレポートの各セクションをcsvファイル化する際のポイント(メモ)"

| | コメント (0) | トラックバック (0)

2018年4月 2日 (月)

Oracle Database Connect 2018

今年もOracle Database Connect の季節がやってきました!

昨年までの大きな会場での開催ではなく、
日本オラクル青山センターでの開催となります。

Oracle Database Connect 2018 / JPOUG告知ページ
http://www.jpoug.org/2018/03/20/odc2018

そして、私も、雛壇DBエンジニアとして参加予定です(ボケ担当?!)


皆さんと、お会いできることを楽しみにしています :)

20160805_134656

| | コメント (0) | トラックバック (0)

2018年3月29日 (木)

Oracle JavaScript Extention Toolkit(JET) de ブラウザの性能比較

なんだか余裕ないので、ちょいと、息抜きw

Oracle JavaScript Extention Toolkit(JET)
Oracle JET

続きを読む "Oracle JavaScript Extention Toolkit(JET) de ブラウザの性能比較"

| | コメント (0) | トラックバック (0)

2018年3月18日 (日)

Temp落ち #9 - 自動PGA管理で_pga_max_sizeと戯れたPGAサイズって本当に使えるのか? 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理下で、_pga_max_size隠しパラメータとpga_aggregate_targetを最大値に設定するした場合、global memory boundは
最大で、約839GBまで増加することがわかりました。

ただ、これは、内部的なパラメータ上の話。


今日は、実際にソートやハッシュ結合を行なわせ、PGAのSQL Work Areaサイズがどこまで利用できるものなのか確認してみることにします。

さて、どういう結末になりますやら(w

随分前から同じようなことを試している方はいますし....:)

なぜ今そこをdiggingしちゃってるのか? って?

メモリーたっぷりあるのに、何故Temp落ち? が話題になったからに決まってるじゃないですかw

続きを読む "Temp落ち #9 - 自動PGA管理で_pga_max_sizeと戯れたPGAサイズって本当に使えるのか? 12.2.0.1版"

| | コメント (0) | トラックバック (0)

2018年3月12日 (月)

Temp落ち #8 - 自動PGA管理でパラメータ上設定可能な最大サイズは?(実際に利用可能なサイズとは限りませんが。意味深) 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理下では、SQL Work Areaサイズは、pga_aggregate_targetのサイズに応じて変化し、最大1GBまで調整され、それのサイズ以上のソートやハッシュ結合は、もれなく、"Temp落ち" する。
手動PGA管理下では、最大2GBまで指定できました。。自動だと1GBまでなのか。。。と残念がる声が、昔は海だった方面から聞こえた気がしましたが、たぶん、気のせいw

というところまででした。


今日は、自動PGA管理下ではそれが最大なのか? のか? 自己責任で試してみることにしますw

まずはこれまでの復習。

自動PGA管理で、SQL Work Areaサイズの算出に関わるパラメータは以下の通り

pga_aggregate_target = 10MB 〜 4TB - 1
_pga_max_size = 200MB 〜 2GB
Oracleが動的に値を調整している_pga_max_sizeパラメータへユーザーが値を設定してしまうとOracleの自動調整が無効化され、設定した値で固定されてしまうので注意が必要です。

私の観測範囲だとおおよそ以下のように変化します。最近は大量のメモリーを搭載したサーバーが多いので、pga_aggregate_targetが10GB以上という状況も普通になってきたので、自動PGA管理下のSQL Work Areaサイズは最大1GBとざっくり丸暗記しても困ることは思いますw(ちょっと乱暴かw)

pga_aggregate_target = 10MB〜10GB - 1 :
_pga_max_size = 200MB 〜 2047MB
GREATEST(pga_aggregate_target*0.2 ,200MB)

pga_aggregate_target = 10GB以上〜4TB-1 :
_pga_max_size = 2GB
LEAST(pga_aggregate_target*0.2 ,2GB)


_pga_max_sizeはpga_aggregate_targetの値に応じて動的に変化し、それらを元に _smm_max_size が算出される
LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)

pga_aggregate_target = 10MB〜10GB-1
_pga_max_size = 200MB〜2047MB
_smm_max_size = 2MB〜1023MB


pga_aggregate_target = 10GB〜4TB-1
_pga_max_size = 2048MB
_smm_max_size = 1024MB
_smm_max_sizeは、v$pgastatのglobal memory boundだろうということは確からしいということまでは確認しました。

20180307_143308
20180307_143330
いままでの結果をまとめると
PGAのSQL Work Areaサイズの最大サイズを示す global memory boundは、pga_aggregate_targetが10MB〜10GB-1までは2MB〜1023MBで調整され、pga_aggregate_targetが10GB〜4TB-1では、1024MB (1GB) で固定されている、というのが、Oracle 10GR2〜12cR2まで動きであることは間違いなさそう:)

続きを読む "Temp落ち #8 - 自動PGA管理でパラメータ上設定可能な最大サイズは?(実際に利用可能なサイズとは限りませんが。意味深) 12.2.0.1版"

| | コメント (0) | トラックバック (0)

2018年3月 8日 (木)

Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理で利用可能なSQL Work Areaサイズはいくつなのか?の確認でした。
これまで同様、隠しパラメータ等の変更をしないデフォルトの設定では最大1GBまで到達することを確認しました。
また、手動PGA管理で利用可能な最大サイズより小さいことも再確認しました。


今日は自動PGA管理下ではオンメモリーで処理可能なサイズは1GBまでなのか、それを超えた場合はもれなく "Temp落ち" なのか確認することにします。

続きを読む "Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版"

| | コメント (0) | トラックバック (0)

2018年3月 7日 (水)

Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版

Previously on Mac De Oracle
pga_aggregate_target scope=memory or bothでそれまでとはことなる動きとエラーは発生するところの話でした。


きょうは、自動PGA管理下ではどうなるか確認しておきます。
以前、簡単に確認した範囲結果から、これまでの仕様と大きな違いはないとみています。(変わっていないと思っていたのでブログでも書いていなかったのですが、"Temp落ち"ネタの準備運動も兼ね現状を確認しながら進めてみたいと思います)


まず環境情報から、
確認に利用するインスタンスのPGA以外のパラメータは以下の通りです。
(隠しパラメータは必要がある場合には適宜変更します。また、いくつかのパラメータは確認の都合上物理メモリーサイズ以上に設定することがあります。それらの変更が必要な場合には事前に解説する予定です。)

OS等の情報は以前のエントリーを参照のこと。

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sga_max_size big integer 12G
sga_min_size big integer 0
sga_target big integer 12G

今回の主役である自動PGA管理のパラメータの初期設定は以下の通り(隠しパラメータを除く)
pga_aggregate_limit = 0 に設定し、pga_aggregate_targetの上限値制限を仕様上のサイズ4096GB - 1まで利用できるようにしておきます。(以前と同様の手順で確認するために、pga_aggregate_limitによる制限を無効化しています。なお、pga_aggregate_limitを0以外に設定して行う場合には、pga_aggregate_targetを4TB - 1まで設定することを考慮すると、pga_aggregate_limitは、8TB以上に設定する必要があります。)

orcl12c@SYS> show parameter pga_aggregate

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_limit big integer 0
pga_aggregate_target big integer 10M

上記設定からスタートして、pga_aggregate_targetを10MB/50MB/100MB/500MB/1GB/5GB/10GB/50GB/100GB/500GB/1T/4TB - 1と増加させながら、pgaサイズおよび、関連する隠しパラメータ(_pga_max_sizeや_smm_*など)がどのように変化するか、pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8の手順で確認します。

続きを読む "Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版"

| | コメント (0) | トラックバック (0)

2018年2月24日 (土)

Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版 (その前に少し脱線)


Previously on Mac De Oracle

手動PGA管理下で利用される4つのパラメータ(HASH_AREA_SIZE / SORT_AREA_SIZE / BITMAP_MERGE_AREA_SIZE / CREATE_BITMAP_AREA_SIZE)は、Integer型であり2,147,483,647バイト(つまり2GB - 1)までは指定可能、かつ、個々の作業領域は同程度確保されること。そのサイズを超えるデータ量の場合は一時表領域が利用される。つまり"Temp落ち"が発生するというところまでした。

SQL> show parameter _area_size

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
bitmap_merge_area_size integer 2147483647
create_bitmap_area_size integer 2147483647
hash_area_size integer 2147483647
sort_area_size integer 2147483647

64bit環境でInteger型なので、そんなもんでしょうね。 仕様ですからね、こればっかりはどうにもならない。


で、自動PGA管理で確認しようとパタパタ準備していたところ、12.1.0.2まではなかった12.2.0.1での変更点に気付いたので、そちらを先に。
(少し脱線)

続きを読む "Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版 (その前に少し脱線)"

| | コメント (0) | トラックバック (0)

2018年2月22日 (木)

Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認


Previously on Mac De Oracle
手動PGA管理で作業領域として指定可能な最大サイズは、2GB - 1までということの確認でした。
本当に、その程度のサイズまでPGAの作業領域が利用されるのでしょうか?。 念のために確認しておきましょう。
実は、それより少ないサイズで頭打ちなんてことは、ないかな〜 と わざとらしく言ってみたりして(意味深w

その前に、指定した作業領域を使い切れるぐらい(つまり、Temp落ちさせられる程度)のデータ量の表を準備しておきます。
今回は、Nested Loop Join(NLJ)やソート回避などのための索引は作成しません。Temp落ちのネタなので。

M1とM2の2表を作成し、それぞれ、2.5GB程度のセグメントサイズにしておきます。
なお、以下の無名PL/SQLブロックでは、FORALLを利用して1000行単位でバルク処理しています。配列を利用するのでメモリー使用量にはそれなりに配慮が必要ですが。:)
単純なぐるぐる系INSERTにしてしまうとデータ量が多い場合、性能的に辛くなってしまうので、ここ重要!

ORCL@SCOTT> l
1 CREATE TABLE m1
2 (
3 id CHAR(7) NOT NULL
4 ,rev# NUMBER NOT NULL
5 ,value NUMBER NOT NULL
6 ,description VARCHAR2(4000)
7 ,additional_info CHAR(200)
8* ) NOLOGGING
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> l
1 DECLARE
2 TYPE IDS_t IS TABLE OF m1.id%TYPE INDEX BY PLS_INTEGER;
3 TYPE REV#S_t IS TABLE OF m1.rev#%TYPE INDEX BY PLS_INTEGER;
4 TYPE VALS_t IS TABLE OF m1.value%TYPE INDEX BY PLS_INTEGER;
5 IDs IDS_t;
6 REV#s REV#S_t;
7 VALs VALS_t;
8 k PLS_INTEGER := 1;
9 BEGIN
10 FOR i IN 1..100000 LOOP
11 FOR j IN 1..10 LOOP
12 IDs(k) := 'C' || TO_CHAR(i, 'FM000000');
13 REV#s(k) := j;
14 VALs(k) := i + j;
15 k := k + 1;
16 END LOOP;
17 IF MOD(i, 100) = 0 THEN
18 FORALL l in 1..1000 EXECUTE IMMEDIATE
19 'INSERT /*+ APPEND_VALUE NO_GATHER_OPTIMIZER_STATISTICS */ INTO m1 '
20 || 'VALUES(:1, :2, :3, LPAD(''X'',2000, ''X''), LPAD(''9'',200,''9''))'
21 USING IDs(l), REV#s(l), VALs(l);
22 COMMIT;
23 k := 1;
24 END IF;
25 END LOOP;
26* END;
ORCL@SCOTT> /

PL/SQL procedure successfully completed.

Elapsed: 00:01:22.45
ORCL@SCOTT> select count(1) from m1;

COUNT(1)
----------
1000000

ORCL@SCOTT> select segment_name,sum(bytes)/1024/1024/1024 "GB" from user_segments where segment_name='M1' group by segment_name;

SEGMENT_NAME GB
------------------------------ ----------
M1 2.5625

ORCL@SCOTT> l
1 CREATE TABLE m2
2 (
3 id CHAR(7) NOT NULL
4 ,rev# NUMBER NOT NULL
5 ,value NUMBER NOT NULL
6 ,description VARCHAR2(4000)
7* ) NOLOGGING
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> l
1 INSERT /*+ APPEND NO_GATHER_OPTIMIZER_STATISTICS */ INTO m2
2* SELECT id,rev#,value,description FROM m1
ORCL@SCOTT> /

1000000 rows created.

Elapsed: 00:00:40.22
ORCL@SCOTT> commit;

Commit complete.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'M1',no_invalidate=>false,method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY');

PL/SQL procedure successfully completed.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'M2',no_invalidate=>false,method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY');

PL/SQL procedure successfully completed.

これで、準備完了。
ちなみに、NO_GATHER_OPTIMIZER_STATISTICSヒントを利用していますが、データ登録後に、ヒストグラムも含めて取得したかったため、バルクロード時のオンラインオプティマイザ統計収集を行わないようにするためのヒントです。
データ登録後オプティマイザ統計を取得するため、データ登録時のオンラインオプティマイザ統計のオーバーヘッドは無駄となるためです。利用できるなら利用したほうがよいとは思いますが、制限もあるのでご一読を(バルク・ロードのためのオンライン統計収集



続きを読む "Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認"

| | コメント (0) | トラックバック (0)

2018年2月20日 (火)

Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ

自動PGA管理は12cでどうなんだっけ?という確認の前に、
いままで何度か質問されたことがあり、FAQだと思っているので

手動PGA管理で利用する以下パラメータの最大サイズはいくつ? 

HASH_AREA_SIZE
SORT_AREA_SIZE
BITMAP_MERGE_AREA_SIZE
CREATE_BITMAP_AREA_SIZE

ということを書いておきたいと思います。

これからしばらく続く Temp落ち ネタで利用する環境で固定部分は以下のとおり
(初期化パラメータ等は必要に応じて載せるつもりです。)


環境は以下のとおり。
host osとguest osのバージョンやメモリーサイズなど

discus:˜ oracle$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.13.3
BuildVersion: 17D47

discus:˜ oracle$ system_profiler SPHardwareDataType | grep -E 'Processor Name|Cores|Memory'
Processor Name: 6-Core Intel Xeon
Total Number of Cores: 12
Memory: 32 GB

discus:˜ oracle$ VBoxManage -v
5.2.6r120293

discus:˜ oracle$ VBoxManage showvminfo e3d4f948-b2e6-4db3-a89d-df637d87a372 | grep -E 'Memory size|OS type|Number of CPUs'
Memory size: 23569MB
Number of CPUs: 12
OS type: Linux26_64


orcl12c@SYS> select * from v$version;

BANNER CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production 0
PL/SQL Release 12.2.0.1.0 - Production 0
CORE 12.2.0.1.0 Production 0
TNS for Linux: Version 12.2.0.1.0 - Production 0
NLSRTL Version 12.2.0.1.0 - Production 0


orcl12c@SYS> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 ORCL READ WRITE NO

さて、今日の本題

手動PGA管理で各SQL Work Area Sizeを決定する以下の初期化パラメータの最大サイズは? いくつでしょう? 
すでにご存知のかたはスキップしていいですよ:)

続きを読む "Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ"

| | コメント (0) | トラックバック (0)