如果你要說這個CDB,PDB的區別和聯絡，那我就直接上一張圖。

這個圖我們以往看到的體系結構圖不大一樣，可以理解是在Oracle的地基上做了較大的改動，就好比一個家大業大的豪門，現在要把資產分開管理，也就是多個PDB,裡面CDB還是核心的容器，但是不負責具體的資料，只是統籌管理。

以往我們說資料字典分為兩類，資料字典表和動態效能檢視，資料字典表按照層級可以分為DBA_XXX,ALL_XXX,USER_XXX這三個層級，在12c裡面這個地方又有了變化，那就是有了更高階的CDB_XXX這個層級的資料字典表。

好了，基礎的部分就先說到這裡，問題來了，我們現在的環境融合了多套測試環境，也就是含有多個PDB,這個時候知道Scheduler Job出現問題，我們怎麼進一步定位呢，一個很自然的思路就是檢視CDB_XXX的資料字典表。

我們來看看具體的表現，環境是12.1.0.2。

可以檢視cdb_scheduler_job_run_details來得到詳細的資訊。

SQL> select status,count(*) from cdb_SCHEDULER_JOB_RUN_DETAILS where log_date>sysdate-1 group by status;
STATUS                           COUNT(*)
------------------------------ ----------
SUCCEEDED                            2984
FAILED                                  4
 

我們繼續檢視，怎麼這麼奇怪。

SQL> select *from cdb_SCHEDULER_JOB_RUN_DETAILS  where status='FAILED';
ERROR:
ORA-00942: table or view does not exist

我們繼續換個姿勢來看看。

SQL> select count(*)from cdb_SCHEDULER_JOB_RUN_DETAILS  where  log_date>sysdate-1 and status='FAILED';
  COUNT(*)
----------
         4

這樣就沒問題了，我們更進一步看看。

SQL> select *from cdb_SCHEDULER_JOB_RUN_DETAILS  where status='FAILED';
ERROR:
ORA-00942: table or view does not exist

由此來看，CDB_XXX的資料字典還是存在著一些小問題。怎麼進一步去細分呢。我們可以藉助於容器ID,CON_ID,然後結合DBA_SCHEDULER_JOB_RUN_DETAILS。

如果想把這個問題刨一刨，其實也能發現一些資訊，本身在CDB的資料字典上還是存在著一些小問題，我想這些資料字典可能使用的不是特別頻繁，可能這個問題被遺漏了，所以在一個成熟的架構上做改動，那是迫不得已，而在改動上面希望做到無縫切換，那更是難上加難。我想12.2應該會修復了吧。

12.2已經做出了太多的改變，很多不可以的事情都實現了。不過相對來說，這個cloud推出的是比較吃力，讓一大批死忠粉等待的時間有些太長了。戰略上的佈局要擲地有聲，而市場上的成功更要需要花費不少的時間，錯一步，步步錯，所以我可以感覺Oracle也在很謹慎的在生態中佈局。