2017年10月 7日 (土)

SQL Tuning Setのキャプチャから退避までのスクリプト(やっつけ)

Previously on Mac De Oracleは
DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよwという備忘録でした、

今回は
以下のURLで紹介されているSTS (SQL Tuning Set)へSQLの性能統計や実行計画をキャプチャしちゃおう!
Oracle DatabaseのSTS(SQL Tuning Set) を活用して、SQLの性能統計や実行計画をキャプチャする。 / ora_gonsuke777

というSTS機能を利用した応用編w (という名のやっつけスクリプト) を書いたので、備忘録

STSでSQLの実行計画や性能統計をキャプチャするのはいいのですが、キャプチャするデータが多い場合、SYSAUX表領域を圧迫したり、拡張したりしてしまうことがあります。
本番環境で表領域サイズにドキドキする日々を送るのも嫌なので、一定期間STSヘキャプチャしたあとSTSを退避、削除したいよね。という方向の話が湧いてきたりしますw

続きを読む "SQL Tuning Setのキャプチャから退避までのスクリプト(やっつけ)"

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

2017年10月 6日 (金)

DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw

ということで、タイトル通り
マニュアル上、例外を投げるとは記載されてないのですが、テストしてたら”例外投げる”PL/SQLプロシージャ、意外と多いんですw
意図的に例外投げるよーというのは大抵マニュアルに記載されているんですが。人が書いてますからね、記載漏れも仕方ないっすねぇw 

マニュアルバグ、忘れちゃうので、自分向けFAQ and 備忘録 


Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 12c リリース1 (12.1) B71281-05
DBMS_SQLTUNE.PACK_STGTAB_SQLSETプロシージャ

Oracle Database PL/SQL Packages and Types Reference (12.2)のマニュアルには DBMS_SQLTUNE.PACK_STGTAB_SQLSET Procedure は例外を投げるよ!という記載はないが...

DBMS_SQLTUNE.PACK_STGTAB_SQLSET Procedure
DBMS_SQLTUNE.PACK_STGTAB_SQLSET Procedure

続きを読む "DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw"

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

2017年9月 1日 (金)

ORA-12034 #2

前回の通り、高速リフレッシュの間にdata pump export / importを完了させれば、ORA-12034なんて起きないはず。

VirtualBoxの環境は試験開始前のスナップショットで戻してあります
20170415_14044_2

SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 28 20:57:49 2017

Copyright (c) 1982, 2014, Oracle. All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

orcl@MVIEW_SCHEMA1> @mview_info_c
Connected.

¥Session altered.

ROWNER RNAME REFGROUP JOB B INTERVAL NEXT_DATE CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1 MV_MASTER 61 81 N sysdate+5/1440 2017/08/28 21:00:54 3

MVIEW_NAME REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER DEMAND FAST FAST UNDEFINED VALID

JOB LOG_USER SCHEMA_USER LAST_DATE NEXT_DATE INTERVAL FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
81 MVIEW_SCHEMA1 MVIEW_SCHEMA1 2017/08/28 20:55:54 2017/08/28 21:00:54 sysdate+5/1440 0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

前回は5分間隔だったので、余裕をもたせて30分にしてあります。
本番環境で5分間隔の高速リフレッシュを30分にしたり、止めたりってことはかなり敷居が高いとは思いますが、そのあたりは空気を読んで対応する必要があるかと。 :)

orcl12c@SYS> conn mview_schema1@orcl
Connected.
orcl@MVIEW_SCHEMA1> alter materialized view mv_master refresh next sysdate+30/1440;

Materialized view altered.

orcl@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.


ROWNER RNAME REFGROUP JOB B INTERVAL NEXT_DATE CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1 MV_MASTER 61 81 N sysdate+30/1440 2017/08/28 21:30:36 3

MVIEW_NAME REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER DEMAND FAST FAST UNDEFINED VALID

JOB LOG_USER SCHEMA_USER LAST_DATE NEXT_DATE INTERVAL FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
81 MVIEW_SCHEMA1 MVIEW_SCHEMA1 2017/08/28 20:55:54 2017/08/28 21:30:36 sysdate+30/1440 0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

続きを読む "ORA-12034 #2 "

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

2017年8月31日 (木)

ORA-12034

一ヶ月の家庭内、ワンオペも無事終了したので、ブログも今年前半のペースで再開か!?w

ということで、
以前ちょっとだけ書いた高速リフレッシュを止めてないと完全リフレッシュが必要になってしまう。タイミングの問題にフォーカスしてみようと思います。

どのようなタイミングの問題かというと、

ORA-12034: materialized view log on "xxxxxx"."xxxxxxx" younger than last refresh

出会った方も意外と多かったりしてw 

前述のエラーは、materialized view logが絡んいるので、”高速リフレッシュ”時に発生するエラーです!
高速リフレッシュを行なっている環境でこの状態になってしまうと、”高速リフレッシュ”の再開には”完全リフレッシュ”が必須となってしまうところが怖いというか面倒くさいところ。
マスターサイトも含めて同期するサイズが小さければ完全リフレッシュも面倒なことにならない場合もありますが、数十GB以上の巨大なマテビューだったら、どうします???
マテリアライズドビューのリフレッシュ間隔が短いシステムだと、完全リフレッシュに要する時間が大問題になることも... (色々な状況が想定されていない構成だと、そうなりやすい.....なw

もう少し簡単に言うと、
materialized view logの伝播が必要なデータ有無に関係なく、リフレッシュ時刻を跨いてしまうかどうか! なんですよね、これ。

続きを読む "ORA-12034"

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

2017年7月29日 (土)

SQLとPL/SQLで「モルダー、あなた疲れてるのよ」を出力する方法

もうかれこれ1年以上経過しているので、何を今更という感じがしないでもないですがw

ここ2週間くらい、SQLチューニングじゃない方向で、非常に忙しかったこともあり

気分的に疲れてしまったので、気分転換のために作ってみました。

Ruby でモルダー、あなた疲れてるのよを出力する方法

Pythonでモルダー案件

Groovyで「モルダー、あなた疲れてるのよ」に対処する

と、どう見てもPL/SQLやSQL案件ではないネタですが、PL/SQL de Python Challenge精神(どんな精神じゃw)で無理やり案件化して見ました。

疲れてる時に疲れるネタやるの?、バカなの? 
とお感じの方もお多いかと存じますが、可能ならもっと変態的なネタに発展することを願いつつ、ご挨拶と代えさせていただきます

続きを読む "SQLとPL/SQLで「モルダー、あなた疲れてるのよ」を出力する方法"

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

2017年7月12日 (水)

SQLチューニング祭りの記録-随時更新(祭りじゃないのもあるけど)

Oracle DatabaseのSQLチューナーとしてのデビューは2005年ぐらいで、ちょうど12年:)
Twitterで結果報告?w するようになったのは2011年ごろから。

なんだか当時のプロジェクトを思い出して、あんな人いたっけなー、などと思い出しながら、ニヤニヤしてましたw


SQLチューニング祭りにも色々ありますが、お祭りと化す状況だと、ほとんどの場合、

SQL文書き換えたくない

ビームが放たれることが多いんですが、
最終的に必要最低限ということで、ヒントは使えることは多いんですよね。
(外科的手術が必要なSQLの遅延もあります。。。けどね)

SPMという手もありますが、そもそもハードパースが遅いとSPMどころじゃなかったりw

疲れすぎて、twするのも忘れっちゃったりするので、twしたやつは随時更新予定:)

続きを読む "SQLチューニング祭りの記録-随時更新(祭りじゃないのもあるけど)"

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

2017年7月 1日 (土)

リソースマネージャ:MTA環境のインスタンスケージングが効いているかざっくり確認するスクリプト

元になるビューは1分間隔で更新されているようで秒単位の粒度では確認できないもののざっくりでもいいからリアルタムに確認したい場合には便利

むかーしやった検証はnon CDBかつ、秒単位で見たいという要望だったため他のビューから算出したこともあり、ここで利用しているv$rsrcmetricの類は使わなかったことを思い出した。
完全に忘れてた(@@)。
2年も触らなきゃ忘れるさ。人間だものw orz.

ということで、 Oracle Database 12c 12.1.0.2.0 向けのメモ

注)以下、CDB$ROOTに接続してSQL文を実行しています


利用環境は以下の通りのMTA

orcl12c@SYS> select * from v$version;

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


CPUは4 (VMですが)

orcl12c@SYS> show parameter cpu_count

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
cpu_count integer 4


ORCLとORCL2という2つのPDB対してCPUのUTILIZATION_LIMITでCPU利用率を制限しています。
12.2以降はPDBのインスタンスケージングもnon-CDB環境同様に、CPU_COUNT設定+リソースマネージャで制御できちゃうらしい。わかりやすくて良い!(時間があればいずれ)

orcl12c@SYS> select name from v$containers;

NAME
------------------------------
CDB$ROOT
PDB$SEED
ORCL
ORCL2


orcl12c@SYS> r
1 SELECT
2 vc.name
3 , vp.utilization_limit
4 FROM
5 v$rsrc_plan vp
6 INNER JOIN v$containers vc
7 ON vp.con_id=vc.con_id
8 ORDER BY
9* vc.con_id

NAME UTILIZATION_LIMIT
------------------------------ -----------------
CDB$ROOT
PDB$SEED
ORCL 25
ORCL2 50

続きを読む "リソースマネージャ:MTA環境のインスタンスケージングが効いているかざっくり確認するスクリプト"

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

2017年6月17日 (土)

SQL Developer de Real time SQL monitoring / FAQ

Oracle Database 12c EEかつ、Diagnostic Pack / Tuning Packもあるのに
SQL real time monitoringしないのはもったいないという話から、
http://www.oracle.com/technetwork/jp/ondemand/db-basic/d-16-ssqltuning-1448439-ja.pdf

EMなくても簡単にできないのか? 

と聞かれたので

おすすめなのが、SQL Developer

SQL Developer 4.2
http://www.oracle.com/technetwork/jp/developer-tools/sql-developer/downloads/index.html

テキストよりGUIでという方にはおすすめ。

細けーはなしはいつか書くつもりですが、とりあえず、こんなことを確認できるんでっす。

20170617_110017

20170617_110411


20170617_110436


!!!!!ここ重要!!!!!
以下のダイアログには、Tuning Packが必要とありますが、Tuning Packを利用するにはDiagnostic Packが必要なので、 Real time SQL monitoringを行うには、Diagnostic PackとTuning Packの両方が必要というこなので、間違わないようにしてくださいませ。マニュアルにはしっかり書かれてますが、折角ダイアログで警告してるのにコメントが残念な。
https://docs.oracle.com/cd/E57425_01/121/DBLIC/options.htm#CIHFIHFG

20170617_110454

20170617_121606


20170617_121624


20170617_121629


20170617_121637


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

2017年6月 9日 (金)

Known Issues for Oracle Database Cloud Service / 始めるまえに読んでおこうね

Known Issues for Oracle Database Cloud Service
https://docs.oracle.com/cd/E60665_01/dbcs_dbaas/KIDBR/toc.htm

を見ると既知の問題が結構あります。 エグいのもw

でも Oracle iASやらOracle Portal Server (もう17年ぐらい前だよねw)の時は、そんなの比べ物にならないくらい、既知の問題があって、やる気あんのかw ぐらいに思ってたことがあったので、これぐらいの量じゃ驚かないw
(麻痺してる?w)


課金そのままで、「Standard Edition OneデータベースがEnterprise Editionになっている可能性がある」なんてのもあるらしい。
https://docs.oracle.com/cd/E60665_01/dbcs_dbaas/KIDBR/index.html#kidbr-GUID-EF96077B-2E54-4461-A825-51F8E8194D77

「15.3.5イメージを使用して作成されたサービス・インスタンスのロールバックでv$optionsが無効になる」
v$optionsってなに? とおもったが、v$optionのことだったやつとか
https://docs.oracle.com/cd/E60665_01/dbcs_dbaas/KIDBR/index.html#kidbr-#GUID-0AFC0771-700C-43BC-93B7-BA072768D928

とにかく、やる前に読んでおくと少し幸せになれるかも。

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

2017年5月21日 (日)

FAQ:Solaris 11.3とZFSという組み合わせだとFAQなのな、ZFS ARCに関する動きについて

有名すぎるネタらしいけど、Solaris + ZFSを使うことなんて、、久々すぎて、あーあったっけ〜、そんなOSという感じの久しぶり感。もう二桁何年ぶりちょい前ぶりぐらいに、遠い目w 

ということで、せっかく調べたので、備忘録。


Oracle® Solaris 11.3 カーネルのチューンアップ・リファレンスマニュアル
第 3 章 Oracle Solaris ZFS チューニング可能パラメータ
ZFS メモリー管理パラメータ

カーネルゾーンのメモリーを予約するための ZFS ARC のチューニング
Tuning the ZFS ARC to Reserve Memory for Kernel Zones
ZFS Memory Tuning for Oracle Databases & Application on Oracle Solaris 11
Activity of the ZFS ARC
ZFS Performance Analysis and Tools - Brendan Gregg
Solaris っていまどうなってるの? 2016 末
Oracle® Solaris カーネルゾーンの作成と使用

Solaris 11.3とOracle Database 12.1.0.2を利用して、11.3でもZFS ARCが暴れてしまう状況を再現して見ます。
Oracle Solaris 11.3 VM Template for Oracle VM VirtualBox

bash-4.1$ pkg list entire
NAME (PUBLISHER) VERSION IFO
entire 0.5.11-0.175.3.1.0.5.0 i--
bash-4.1$ uname -r
5.11
bash-4.1$ cat /etc/release
Oracle Solaris 11.3 X86
Copyright (c) 1983, 2015, Oracle and/or its affiliates. All rights reserved.
Assembled 06 October 2015

SQL> select * from v$version;

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


起動直後の状態、freelistは5.9Gほどあり、約3GB程度空いていれば起動できる設定のOracle Databaseを起動するだけの空きメモリがある。

root@angelfish:˜# echo ::memstat | mdb -k
Page Summary Pages Bytes %Tot
----------------- ---------------- ---------------- ----
Kernel 193500 755.8M 9%
ZFS Metadata 23285 90.9M 1%
ZFS File Data 159905 624.6M 8%
Anon 106662 416.6M 5%
Exec and libs 4207 16.4M 0%
Page cache 29519 115.3M 1%
Free (cachelist) 1 4k 0%
Free (freelist) 1561934 5.9G 74%
Total 2097039 7.9G

続きを読む "FAQ:Solaris 11.3とZFSという組み合わせだとFAQなのな、ZFS ARCに関する動きについて"

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

2017年5月 8日 (月)

セマフォ?

Solaris11.3にOracle Database 12.1と12.2をなにげにインスコしてみたところ。。。

12.1.0.2はこんな感じ、processes=300なんで、Linuxでもよく見る感じでセマフォセット3 * セマフォ152(使われてないセマフォセットあり)

SQL> select * from v$version;

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

SQL>
SQL> show parameter processes

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
aq_tm_processes integer 1
db_writer_processes integer 1
gcs_server_processes integer 0
global_txn_processes integer 1
job_queue_processes integer 1000
log_archive_max_processes integer 4
processes integer 300
SQL>

root@angelfish:˜#  cat /etc/release
Oracle Solaris 11.3 X86
Copyright (c) 1983, 2015, Oracle and/or its affiliates. All rights reserved.
Assembled 06 October 2015

root@angelfish:˜# ipcs -a
IPC status from as of 2017年05月07日 (日) 17時58分27秒 JST
T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME
Message Queues:
T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
Shared Memory:
m 28 0xc6002aac --rw-r----- oracle oinstall oracle oinstall 57 16384 1393 1671 17:57:45 17:58:02 17:47:36
m 27 0x0 --rw-r----- oracle oinstall oracle oinstall 57 14680064 1393 1671 17:57:45 17:58:02 17:47:36
m 26 0x0 --rw-r----- oracle oinstall oracle oinstall 57 2566914048 1393 1671 17:57:45 17:58:02 17:47:36
m 25 0x0 --rw-r----- oracle oinstall oracle oinstall 57 4194304 1393 1671 17:57:45 17:58:02 17:47:36
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME
Semaphores:
s 5 0xde1cdf8e --ra-r----- oracle oinstall oracle oinstall 152 17:47:39 17:47:36
s 4 0xde1cdf8d --ra-r----- oracle oinstall oracle oinstall 152 no-entry 17:47:36
s 3 0xde1cdf8c --ra-r----- oracle oinstall oracle oinstall 152 17:58:25 17:47:36
root@angelfish:˜#

続きを読む "セマフォ?"

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

2017年5月 7日 (日)

dbms_stats.export_[schema|table]_stats/dbms_import_[schema|table]_stats : 索引名の変化に追随できるようになった?のか?

Oracle Database PL/SQLパッケージおよびタイプ・リファレンス 12c リリース2 (12.2) DBMS_STATSサブプログラムの要約
Oracle Databaseユーティリティ 12c リリース2 (12.2) 3 データ・ポンプ・インポート



dbms_stats.export_[schema|table]_stats/import_[schema|table]_statsを利用してオプティマイザ統計を移植する際、
一意制約や主キー制制約作成でシステム生成の索引名を持つ索引へオプティマイザ統計をインポートできない。(しかもエラーもワーニングも表示されない)
この問題、私が遭遇したのは11g R1のころだったと記憶している(詳しく調べたわけではないので、11g R1で初めて発覚した問題なのかそれ以前からあった問題なのか不明です)が、
オプティマイザ統計をdbms_stats.export_[schema|table]_stats/import_[schema|table]_statsを利用して、
以下のような内部的に付与される索引名を持つ索引へオプティマイザ統計を移植するのはたーーーいへん。というお話です。

主キー制約の例ですが、制約に名称を付与せず名称をOracle任せにする記述方法と、制約名と同じ名称で関連する索引を作成する記述方法があります。(事前に索引を作成しておく方法もありますが今回はあまり関係ないので省略)

例1

SCOTT> create table hoge
2 (
3 id number primary key
4 ,foo number
5 );

表が作成されました。


例2

SCOTT> create table hoge2
2 (
3 id number not null
4 ,foo number
5 ,constraint pk_hoge2 primary key(id) using index
6 );

表が作成されました。

例1の主キー制約で作成された制約及び索引は以下のようにSYS_Cnnnnnnという形式でOracleが名称を生成します!
data pumpによりインポートややDDLを再利用して他のスキーマやデータベースへ複製すると、都度、名称が異なることを意味します。それが問題の根っこ。

SCOTT> select table_name,index_name,num_rows,last_analyzed from user_ind_statistics where table_name like 'HOGE%';

TABLE_NAME INDEX_NAME NUM_ROWS LAST_ANALYZED
------------------------------ ------------------------------ ---------- -------------------
HOGE SYS_C009918
HOGE2 PK_HOGE2


Data Pumpやdbms_stats.export_[schema|table]_stats/dbms_import_[schema|table]_statsを利用したエクスポート/インポートで、元と先の名称の違いを解決できないとオプティマイザ統計がインポートできないという事態になります。
そこで、エクスポートした索引名とインポート先の索引名が異なっていてもオプティマイザ統計を正しくインポートする為には、元と先の名称をマッピングする機能の登場となるわけです。

マニュアルを読むと、Data Pumpにもdbms_stats.export_[schema|table]_stats/import_[schema|table]_statsにも、マッピングに関する記述があるので、その点は意識されている仕様になっている、ように見えます。
が、マッピングに関する部分を読んでも、Data Pumpとdbms_stats.export_[schema|table]_stats/import_[schema|table]_statsに同様のマッピング機能があるようには見えないんですよ。これがw。そうなれば試してガッテンw 差異を以下にまとめました!

知ってる方々にはFAQ(多分、ハマった経験からか?w)なのですが、意外に知られてないようなので忘れないうちに書いておきます:)
なお、12cになってから少々動きが変わったのでその点にも注意が必要でっす!


11.1.0.7 → 11.1.0.7 : NG (dbms_stats.upgrade_stat_tableプロシージャでのSTATTABのアップグレード不要)
11.1.0.7 → 11.2.0.1 : NG (同上)
11.1.0.7 → 12.1.0.2 : NG (dbms_stats.upgrade_stat_tableプロシージャでのSTATTABのアップグレード必要)
11.1.0.7 → 12.2.0.1 : NG (同上)

11.2.0.1 → 11.2.0.1 : NG (dbms_stats.upgrade_stat_tableプロシージャでのSTATTABのアップグレード不要)
11.2.0.1 → 12.1.0.2 : NG (dbms_stats.upgrade_stat_tableプロシージャでのSTATTABのアップグレード必要)
11.2.0.1 → 12.2.0.1 : NG (同上)

12.1.0.2 → 12.1.0.2 : OK (dbms_stats.upgrade_stat_tableプロシージャでのSTATTABのアップグレード不要)
12.1.0.2 → 12.2.0.1 : OK (dbms_stats.upgrade_stat_tableプロシージャでのSTATTABのアップグレード必要)

12.2.0.1 → 12.2.0.1 : OK (dbms_stats.upgrade_stat_tableプロシージャでのSTATTABのアップグレード不要)


ちなみに、Data Pumpによるexport/importでは索引名の変化には追随しているようなので、dbms_statsを利用した移植のみ注意が必要です。
Data Pumpを利用したオプティマイザ統計の移植ではdbms_stats利用時と同パターンであっても以下の通りの違いがあります。(とは言っても簡単な確認だけなので落とし穴がないとはいえませんけど)

索引名をOracleの自動付与にしないのが一番の対策だと思います。


11.1.0.7 → 11.1.0.7 : OK
11.1.0.7 → 11.2.0.1 : OK
11.1.0.7 → 12.1.0.2 : OK
11.1.0.7 → 12.2.0.1 : OK

11.2.0.1 → 11.2.0.1 : OK
11.2.0.1 → 12.1.0.2 : OK
11.2.0.1 → 12.2.0.1 : OK

12.1.0.2 → 12.1.0.2 : OK
12.1.0.2 → 12.2.0.1 : OK

12.2.0.1 → 12.2.0.1 : OK

続きを読む "dbms_stats.export_[schema|table]_stats/dbms_import_[schema|table]_stats : 索引名の変化に追随できるようになった?のか? "

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

2017年5月 3日 (水)

XQuartz で X forwarding

ちょっと前に、macOSでssh接続してOracle Universal InstallerとかDBCAとか起動するのはどうするの?
みないな話に割り込んだので、FAQとして書いておきますね。

随分前にも書いてたきがしてけたけど、X11 X forwardingのことを書いてたわけではなかったことに気づいた。orz

X forwardingしたい場合には、terminal.appの代わりにXQuartzを使います

https://www.xquartz.org
20170502_92713
20170502_92412

例えば、macOSのVirtualBoxのLinux/Solarisがguest OSで、そこにOracleをインストールするような場合、
以下のように XQuartsを起動し、X forwarding !!

-Y をお忘れなく!

$ ssh -Y oracle@192.168.1.246

...中略...

-bash-4.1$ ./runInstaller &

...中略...

これだけ。

20170502_92639

続きを読む "XQuartz で X forwarding "

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

2017年5月 2日 (火)

あまりにもネタになってないので、少しだけ sysresv のことを書いといた

共有メモリやセマフォセットの数などの確認は、ipcsでほぼ足りてるわけですが。(複数インスタンスが起動している場合を除く)
あまりにもネタになってないので、少しだけ sysresvのことを書いといた:)

[oracle@vbgeneric ˜]$ sysresv

IPC Resources for ORACLE_SID "orcl12c" :
Maximum shared memory segment size (shmmax): 4398046511104 bytes
Total system shared memory (shmall): 4398046511104 bytes
Total system shared memory count (shmmni): 4096
*********************** Dumping ipcs output ********************

------ Message Queues --------
key msqid owner perms used-bytes messages

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 0 oracle 600 8802304 173
0x00000000 32769 oracle 600 822083584 87
0x00000000 65538 oracle 600 7974912 87
0x21485470 98307 oracle 600 16384 87
0x00000000 262148 oracle 600 524288 2 dest
0x00000000 294917 oracle 600 4194304 2 dest
0x00000000 393222 oracle 600 33554432 2 dest
0x00000000 491527 oracle 600 4194304 2 dest
0x00000000 524296 oracle 600 1048576 2 dest

------ Semaphore Arrays --------
key semid owner perms nsems
0x245b195c 163840 oracle 600 152
0x245b195d 196609 oracle 600 152
0x245b195e 229378 oracle 600 152

*********************** End of ipcs command dump **************


***************** Dumping Resource Limits(s/h) *****************
core file size 0 KB/UNLIMITED
data seg size UNLIMITED/UNLIMITED
scheduling priority 0 KB/0 KB
file size UNLIMITED/UNLIMITED
pending signals 30 KB/30 KB
max locked memory 128 GB/128 GB
max memory size UNLIMITED/UNLIMITED
open files 64 KB/64 KB
POSIX message queues 800 KB/800 KB
real-time priority 0 KB/0 KB
stack size 32 MB/32 MB
cpu time UNLIMITED/UNLIMITED
max user processes 16 KB/16 KB
virtual memory UNLIMITED/UNLIMITED
file locks UNLIMITED/UNLIMITED

***************** End of Resource Limits Dump ******************
Maximum map count configured per process: 65530
Total /dev/shm size: 4050014208 bytes, used: 98304 bytes
Shared Memory:
ID KEY
32769 0x00000000
65538 0x00000000
0 0x00000000
98307 0x21485470
Semaphores:
ID KEY
163840 0x245b195c
196609 0x245b195d
229378 0x245b195e
Oracle Instance alive for sid "orcl12c"
[oracle@vbgeneric ˜]$
[oracle@vbgeneric ˜]$  ipcs -sb

------ Semaphore Arrays --------
key semid owner perms nsems
0x245b195c 163840 oracle 600 152
0x245b195d 196609 oracle 600 152
0x245b195e 229378 oracle 600 152
[oracle@vbgeneric ˜]$  ipcs -st

------ Semaphore Operation/Change Times --------
semid owner last-op last-changed
163840 oracle Tue May 2 01:35:32 2017 Tue May 2 01:26:30 2017
196609 oracle Not set Tue May 2 01:26:30 2017
229378 oracle Tue May 2 01:26:35 2017 Tue May 2 01:26:30 2017

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

2017年4月30日 (日)

Data Pumpも癖モノだよね〜w その6 - schemaモードでMviewを他のPDBへ複製(オプジェクトパスが不足すると...)

Previously on Mac De Oracle

前回は、schemaモードのData PumpでMviewを他のPDBへ複製する際、必要最小限のオブジェクト絞っても可能か? という確認でした。

なんだ、簡単じゃんと、思ったあなた!!
そうでもないんですよ!

SCHEMA_EXPORT_OBJECTSビューより、
オブジェクトパスの親子関係から親をエクスポートすれば子も一緒だねぇ〜。と想像はできるわけですが、
兄弟(TABLEやDB_LINKやMATERIALIZED_VIEW)の場合はそう簡単ではなくて、そもそも依存関係を把握してないとうまく使いこなせないんですよ!

というのが今日のネタ

FAQ!


前回同様、基本レプリケーション環境が完成した状態からエクスポートしてみます。

その前にパラメータファイルに含めるincludeパラメータを確認しておきましょう。
複製に成功したオブジェクトパスは以下でした。
SCHEMA_EXPORT_OBJECTSビューより)

OBJECT_PATH                     COMMENTS
------------------------------- ------------------------------------------------------------
SCHEMA_EXPORT/DB_LINK Private database links in the selected schemas
SCHEMA_EXPORT/TABLE Tables in the selected schemas and their dependent objects
SCHEMA_EXPORT/MATERIALIZED_VIEW Materialized views
SCHEMA_EXPORT/JOB Jobs in the selected schemas
SCHEMA_EXPORT/REFRESH_GROUP Refresh groups in the selected schemas

上記の赤字のオブジェクト(DB_LINK/TABLE/MATERIALIZED_VIEW/JOB/REFRESH_GROUP)はSCHEMA_EXPORTを親とする兄弟という関係なのは見ての通り。

MVIEWをTABLEとして複製の回でお見せしたとおり、MVIEWであってもTABLEのパスでエクスポートすれば、それはMATERIALIZED_VIEWではなく、TABLEだけ(正確に言うと、TABLEとその子孫のオブジェクト)がエクスポートされていました。

つまり、兄弟の場合、親子の場合と異なり関連はあっても自動でエクスポートしてくれるわけではない。という癖が見えてきます。:)
はっ! そうだったのか! という方のために試してみます!


INCLUDE=TABLEとすると、Data Pumpも癖モノだよね〜w その2 - Materialized ViewをTableとして移行するに書いたようにMviewではなくTABLEとしてエクスポートされ、インポートしてもTABLEのままでリフレッユジョブもリフレッシュグループもありませんでした。

では、INCLUDE=MATERIALIZED_VIEWとした場合には、リフレッシュジョブもリフレッシュグループもエクスポートされるんじゃないか? (そうは、うまくはいかないんです!)

[oracle@vbgeneric ˜]$ cat exp_mviewonly.par 
schemas=mview_schema1
include=MATERIALIZED_VIEW:"IN ('MV_MASTER')"

続きを読む "Data Pumpも癖モノだよね〜w その6 - schemaモードでMviewを他のPDBへ複製(オプジェクトパスが不足すると...)"

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