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)

2017年4月25日 (火)

Data Pumpも癖モノだよね〜w その5 - schemaモードでMviewを他のPDBへ複製(オプジェクトパス de 絞り込み)

Previously on Mac De Oracle

前回はschemaモードのエクスポートで、schemaごとまるっと別PDBへインポートしてMviewサイトを複製してみました。意外と簡単なんですよね。Mviewにハマりさえしなければ。
今回は前回同様の構成で、schemaモードでMviewを他のPDBへ複製するのですが、スキーマごとまるっとではなく、エクスポートするオプジェクトパスを必要最小限に絞ってMviewと関連するオブジェクトのみ複製できることを確認しておきます。

前回と同じポンチ絵ですが、
今回は、基本レプリケーション環境は構築済みの状態からスタートします。(つまり、Data Pumpでエクスポートするところから始めます)
細かい操作を確認したい方は、前々回前回のログを参照ください。

20170415_14044


Mviewの複製に必要な最小限のオブジェクトだけData Pumpで複製するために必要なオブジェクトパスはどれなのか確認しておきます。
前々回のエントリでほぼ見えてますが実際にやってみないと”不安”なので (^^;;;。

data pumpのschemaモード向けSCHEMA_EXPORT_OBJECTSにはオブジェクトパスの定義でMviewに関連するオブジェクト全てが定義されていることは何度か書きました。
また、前々回のexpdp/impdpの実行ログでどのようなオブジェクトがエクスポートされ、インポートされていたかも赤字で示しておきました。

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
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01": system/********@orcl2 directory=workdir dumpfile=mview_schema1.dmp logfile=imp_mview_schema1.dmp
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "MVIEW_SCHEMA1"."MV_MASTER" 5.5 KB 2 rows
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at Sat Apr 15 00:39:00 2017 elapsed 0 00:00:23


インポートされたオブジェクト、ジョブ、そして、リフレッシュグループの情報から、schemaモードでMVIEWの複製に必要な必要最小限のオブジェクトパスは以下と推測しました。
なお、CONSTRAINTはTABLEに紐づくので自動的にエクスポートされるのであえて選んでいません。
(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

続きを読む "Data Pumpも癖モノだよね〜w その5 - schemaモードでMviewを他のPDBへ複製(オプジェクトパス de 絞り込み)"

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

2017年4月23日 (日)

Data Pumpも癖モノだよね〜w その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw)

Previously on Mac De Oracle

前回は、Data PumpのschemaモードでschemaごとまるっとMviewサイトを複製してみたところまで、でした。

エントリには記載していなかったログを見ていて驚いた!ことを調査してみる回として”その4と1/2”にしてみましたw

ほんと、癖モノですよねーMviewも!w



なに驚いたのか、その内容から

Data Pumpを利用しMviewを複製する今回の目的の一つである、完全リフレッシュしないでMviewを複製するという目論見が外れていた!!!?

と思われるログが残っていました。

以下のログは、Data Pumpのインポートログとその後のMview関連ビューをリストしたものですが、赤字部分に注目

Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@orcl2 directory=workdir dumpfile=mview_schema1.dmp logfile=imp_mview_schema1.dmp 
Processing object type SCHEMA_EXPORT/USER

・・・中略・・・

Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "MVIEW_SCHEMA1"."MV_MASTER" 5.5 KB 2 rows

・・・中略・・・

Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at Sun Apr 23 20:30:19 2017 elapsed 0 00:00:28

インポート直後、2つのMviewの状態を確認したログですが、B列(DBA_REFRESH.BROKEN列)はどちらも”N"となっておりリフレッシュジョブは停止中です。問題は下のLAST_REF列(DBA_MVIEWS.LAST_REFRESH_TYPE列)がCOMPLETEとなっているというところです。
CON_ID=5は、PDB:ORCL2なのでインポートを行ったPDBを指します。DBA_MVIEWS.LAST_REFRESH_TYPE列は、「最新のリフレッシュに使用されるメソッド:COMPLETE- 最新のリフレッシュが完了した。」と説明されています。??
完全リフレッシュされちゃったの??? 

こうなったらData PumpでMviewが作成された時に完全リフレッシュされちゃうのか、されないのか確認するしかありませんねw。

ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1 MV_MASTER 61 81 N sysdate+5/1440 2017/04/23 20:38:31 5
MVIEW_SCHEMA1 MV_MASTER 61 81 N sysdate+5/1440 2017/04/23 20:43:30 3

MVIEW_NAME REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH COMPILE_STATE CON_ID
------------------------------ ------ -------- -------- ------------------- ------------------- ----------
MV_MASTER DEMAND FAST COMPLETE UNDEFINED VALID 5
MV_MASTER DEMAND FAST FAST UNDEFINED VALID 3

続きを読む "Data Pumpも癖モノだよね〜w その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw)"

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

2017年4月22日 (土)

Data Pumpも癖モノだよね〜w その4 - schemaモードでMviewを他のPDBへ複製

一回、おやすみしましたが、Previously on Mac De Oracle

前々回は、Data Pump、dbms_jobとdbms_schedulerの複雑な関係を紐解いてみました。

今回は、箸休めとして、schemaモードより上位のモードならMviewはMviewのまま複製や移行することは簡単に行えるよね。という確認だけしておこうと思います。
シンプルだと思わせておいて、細けーことやろうとすると一癖ある、まさに癖モノw ということで :)


まずは、おさらいから

data pumpのschemaモード向けSCHEMA_EXPORT_OBJECTSにはオブジェクトパスの定義でMviewに関連するオブジェクト全てが定義されています。

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

一方、tableモード向けTABLE_EXPORT_OBJECTSには、Mview、リフレッシュに必要なJOBやREFRESH GROUPなどのオブジェクトパスが定義されていません。
tableモードでMviewを複製しようとすること自体に無理があるのは明らかですね。MViewとしてエクスポートしたくてもオプジェクトパスが定義されていないのですから。
表を対象としているモードだからそれ以外のオブジェクトパスが定義されていないんだよね〜と、無理やり納得しています:)

orcl@SYSTEM> r
1 select * from TABLE_EXPORT_OBJECTS where
2 object_path like '%/JOB'
3 or object_path like '%/MATERIALIZED_VIEW'
4* or object_path like '%/REFRESH_GROUP'

no rows selected

おさらいはこれくらいにして、schemaモードエクスポートで以下の図に示したようなMviewの複製が行えるか確認しておきます。

ポンチ絵のとおりではあるのですが、簡単に説明すると、
PDB:ORCLの異なるschema間で高速リフレッシュ可能なMviewがあり、Data Pumpのschemaモードを利用して異なるPDBにMviewを複製するというシナリオです。
複製後はMviewサイトが2つになります。

20170415_14044


なぜ、異なるDB(PDB)にMVIEWを複製するシナリオにしたかって?
理由は、DBMS_JOBのジョブは、同一データベース(MTA構成であればPDB毎)でJOB番号により一意に管理されています。
DBMS_JOBのジョブを同一データベース内でexport/importした場合、ジョブが単純に複製される事になりJOB番号の一意制約エラーとなりimportに失敗します。
importできなければ再作成すれば問題ないわけですが、MTA環境なのでわざわざ同一PDB内に作成する必要はないわけです。(手数を減らせるならその方が楽ですから)

エクスポートする前にリフレッシュジョブを一時停止する理由は?
一時停止している理由は静止点を作りたいこともありますが、それをサボると、なかなか理解しにくいタイミングイシューと言われてる事象に遭遇しやすくなるんですよ。(感覚的に)
前述の状況になると高速リフレッシュを再開するには、一度、完全リフレッシュする必要があります。
ここで利用するMviewは2行しかないので完全リフレッシュは苦でもないですが、巨大サイズの表だったら完全リフレッシュはできることなら避けたいですよね。


続きを読む "Data Pumpも癖モノだよね〜w その4 - schemaモードでMviewを他のPDBへ複製"

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

2017年4月12日 (水)

Oracle Database Connect 2017 : 参加報告とお礼

Oracle Database Connect 2017の資料とセッション映像(全てではないようですが)が公開されました。

このような機会を与えてくれた日本オラクルのしばちょうさん、関係者の皆様ありがとうございました。
ドクターG的な感じで伝えられるか不安でしたが、評判は良かったと聞きホッとしているところです:)

Oracle Database Connect 2017 / jpoug.org

Oracle Database Connect 2017資料
http://www.oracle.com/technetwork/jp/ondemand/odc2017-3627481-ja.html


■基調講演

■異なるデータベース間のSQL比較と Oracle Database 12cの新機能
 日本ヒューレット・パッカード株式会社 篠田典良さん

■クラウド運用で省力化! 最新版 Oracle Database を活用した基盤の魅力
 日本オラクル 伊藤 勝一さん

■進化したのはサーバだけじゃない! DBA の毎日をもっと豊かにするユーティリティのすすめ
 NTTデータ先端技術株式会社 吉田成利さん


Oracle Database Connect 2017 つぶやきまとめ #jpoug #oradbc17
https://togetter.com/li/1088687

■エキスパートはどう考えるか? 体感!パフォーマンスチューニング 
 日本オラクル しばちょうさん、津島さん、畔勝さん
 JPOUG 諸橋さん、渡部さん、そして私


ps.
開催前のミーティングで、「イケる、イケる」と自己暗示のように呟いていた、しばちょうさんが印象的でした:)

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

2017年4月10日 (月)

Data Pumpも癖モノだよね〜w その3 - dbms_job と dbms_scheduler との複雑な関係

Previously on Mac De Oracle

前回は、Data PumpとMaterialized Viewという癖モノ二大巨頭を絡ませて見ました。

今回は、三つ巴?な感じでお送りしたいと思います。:)



以下は、Materialized ViewをリフレッシュするDBMS_JOBです。

今頃気づいたか! という感じですが、dbms_job で作成されるJOBは、ALL/DBA/USER_OBJECTSには含まれないのです!!

orcl@USERS> select job,log_user,schema_user,last_date,next_date,interval,failures,what from user_jobs;

JOB LOG_USER SCHEMA_USER LAST_DATE NEXT_DATE INTERVAL FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
21 USERS USERS 2017/04/09 19:18:34 2017/04/09 19:19:34 sysdate+1/1440 0 dbms_refresh.refresh('"USERS"."MVIEW_MASTER"');

orcl@USERS> select object_name,object_type from user_objects;

OBJECT_NAME OBJECT_TYPE
------------------------------ -----------------------
MVIEW_MASTER MATERIALIZED VIEW
SYS_C0014637 INDEX
MVIEW_MASTER TABLE
TOUSERM DATABASE LINK


ここで、注目!!
dbms_jobは、dba_objectsにはカウントされませんが、dbms_schedulerは、object_type=JOBとしてdba_objectsにカウントされるということ!!
以下にある、OBJECT_TYPE=JOBは、OBJECT_NAME=TESTという直前に作成されたdbms_schedulerのJOBだということ!!

ORCL@USERS> begin
dbms_scheduler.create_job (
job_name=>'test'
,job_type=>'PLSQL_BLOCK'
,job_action=>'BEGIN dbms_refresh.refresh(''USERS.MVIEW_MASTER''); END;'
,start_date=>systimestamp
,repeat_interval=>'FREQ=MONTHLY'
,end_date=>systimestamp + interval '1' year
,enabled=>true
,comments=>null
);
end;
/

PL/SQL procedure successfully completed.


なんとまぁ、面倒くさい、DBMS_JOBのJOBも、DBMS_SCHEDULERのJOBも、同じ初期化パラメータ(job_queue_processes)を利用するのにオブジェクト扱いされたりされなかったり、面倒くさい癖モノです。注意しましょうね!!

Oracle® Databaseリファレンス 12c リリース1 (12.1) 1.126 JOB_QUEUE_PROCESSES
https://docs.oracle.com/cd/E57425_01/121/REFRN/GUID-B8B68D16-00A3-43DD-BE39-01F877880955.htm

ORCL@USERS> select object_name,object_type from user_objects;

OBJECT_NAME OBJECT_TYPE
------------------------------ -----------------------
MVIEW_MASTER TABLE
SYS_C0014637 INDEX
MVIEW_MASTER MATERIALIZED VIEW
TEST JOB
TOUSERM DATABASE LINK

続きを読む "Data Pumpも癖モノだよね〜w その3 - dbms_job と dbms_scheduler との複雑な関係"

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

2017年4月 9日 (日)

Data Pumpも癖モノだよね〜w その2 - Materialized ViewをTableとして移行する

Previously on Mac De Oracle

前回はMac De OracleはData Pumpのqueryパラメーターの解析タイミングについて調べたメモでした。

今回はタイトルのとおり、Materialized ViewをTableとして移行していしまおうというお題。
実は、Materialized Viewとして移行しようとして失敗ったのがきっかけで知ったんですけど、あまり書かれていないので仕様だとは思うんですが(そうなんですよね?w)
(癖モノData Pumpと癖モノMaterialized Viewを扱おうとする時点で、すんなり行くわけがない、ぐらいの覚悟はしておいたほうが無難でしょうけど)


ちなみに、今回の内容とは関係ないですが、ViewをTableとしてエクスポートする機能も12cR1から提供されていますね(使ったことはまだないですが)
VIEWS_AS_TABLES
https://docs.oracle.com/database/121/SUTIL/GUID-E4E45E81-5391-43BE-B27D-B763EF79A885.htm#SUTIL3904

Exporting views as tables Oracle Database 12C release 1 (12.1)
http://dbaora.com/exporting-views-as-tables-oracle-database-12c-release-1-12-1/



以下のようなMVIEWがあります。
エクスポート側ではMaterialize Viewとして定義され、自動的にリフレッシュされています。

orcl@USERS>  select object_name,object_type from user_objects where object_name='MVIEW_MASTER';

OBJECT_NAME OBJECT_TYPE
------------------------------ ------------------------------
MVIEW_MASTER MATERIALIZED VIEW
VIEW_MASTER TABLE

orcl@USERS> select job,log_user,last_date,next_date,interval,failures,broken,what from user_jobs;

JOB LOG_USER LAST_DATE NEXT_DATE INTERVAL FAILURES B WHAT
---------- ------------------------------ ------------------- ------------------- -------------------- ---------- - --------------------------------------------------
21 USERS 2017/04/09 14:16:53 2017/04/09 14:17:53 sysdate+1/1440 0 N dbms_refresh.refresh('"USERS"."MVIEW_MASTER"');

続きを読む "Data Pumpも癖モノだよね〜w その2 - Materialized ViewをTableとして移行する"

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

2017年4月 8日 (土)

Data Pumpも癖モノだよね〜w その1 - queryパラメーターの解析タイミング

AWS、MS、Oracle、それぞれのクラウド環境へのデータ移行なんてことも珍しくなくなってきました。
そして移行ツールとしても利用されるData Pump。

でも細かい機能を使おうと調べていると、Data Pump、いろいろ癖があるよなぁ〜。と改めて気づくんですw

ということで、そんな癖もの! Data PumpのFAQっぽいことを備忘録として書いておきますね。(要するに、ハマったこと集w)


 

queryパラメータに記述したwhere句っていつ解析されるかご存知ですか?
expdpコマンドを実行した時点でqueryパラメータのwhere句のシンタックスがチェックされると思う方、手をあげて!

私もそう思ってました、最近までw
あえて書いてるのですから、勘の良いかたなら、ちがうのか! と気づいちゃいますよねw 

そう!ちがうんです!

では、シンタックスエラーのあるqueryパラメータで実行してみますよ。 赤字の部分、where であるべきですが、 while としてあります。パースされればシンタックスエラーとなるはずです!!
いいですか〜〜〜、よ〜〜〜〜く見ててくださいよ〜。みて、みて、みてみてみてみて〜〜〜〜っ

パラメータファイルは以下のとおり

[oracle@crayfish ˜]$ cat query.par
tables=hoge
query=hoge:"while id = 1"


実行してみると、あーら不思議、正常終了してしまいます!

[oracle@crayfish ˜]$ expdp hr/hr@orcl directory=homedir dumpfile=testhr_query45.dmp logfile=testhr_query45.log parfile=query.par

Export: Release 12.1.0.2.0 - Production on Sat Apr 8 00:34:48 2017

Copyright (c) 1982, 2014, Oracle and/or its affiliates. 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
Starting "HR"."SYS_EXPORT_TABLE_01": hr/********@orcl directory=homedir dumpfile=testhr_query45.dmp logfile=testhr_query45.log parfile=query.par
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
. . exported "HR"."HOGE" 0 KB 0 rows
Master table "HR"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for HR.SYS_EXPORT_TABLE_01 is:
/home/oracle/testhr_query45.dmp
Job "HR"."SYS_EXPORT_TABLE_01" successfully completed at Sat Apr 8 00:35:13 2017 elapsed 0 00:00:24

続きを読む "Data Pumpも癖モノだよね〜w その1 - queryパラメーターの解析タイミング"

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