客戶報告，
當他從 Oracle 11.1.0.7 ，遷移到雲環境，並且升級到12.1.0.2。
執行客戶的應用程式測試，發現比以前更慢了。

從AWR report 的"Top 10 Foreground Events by Total Wait Time"和"Wait Classes by Total Wait Time"等資訊，
可以看到 CPU 值升高了。

初步思考，懷疑由於環境的不同，導致效能不同。但是客戶說，這兩個環境的CPU數目/記憶體大小等各方面情況都完全一樣。
那麼就的考慮其他的原因了。

遷移前的環境和遷移後的環境對比，從AWR report 中，可以看到，遷移後的 "Hard parse"  的比例明顯偏高。

***遷移前
Load Profile
Per Second Per Transaction Per Exec Per Call
DB Time(s): 1.1 0.0 0.00 0.00
DB CPU(s): 0.3 0.0 0.00 0.00
Parses: 158.3 4.8
Hard parses: 8.8 0.3 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Executes: 620.2 18.2

***遷移後
Load Profile
Per Second Per Transaction Per Exec Per Call
DB Time(s): 0.8 0.0 0.00 0.00
DB CPU(s): 0.6 0.0 0.00 0.00
Parses (SQL): 375.8 14.7
Hard parses (SQL): 75.2 3.0 <<<<<<<<<<<<<<<<<<<<<<<<< hard parse 大幅度增加
Executes (SQL): 702.7 28.3

客戶報告，在新環境裡，設定了 對 應用中的所有的 SQL文 都追加了 類似於
"SELECT /*+ OPTIMIZER_FEATURES_ENABLE('11.1.0.7') ORDERED INDEX(T0001 T0001_001) NO_USE_HASH(FBM10) */" 的hint之後，
發現效能基本回到了遷移前的水平。

從這一點來考慮，OPTIMIZER_FEATURES_ENABLE，可能是影響到了 optimizer_adaptive_features 功能。這一功能會在SQL文執行
的時候，動態地判斷有沒有更好的執行計劃。而很可能對客戶程式的一部分SQL文，反而動態調整執行計劃產生了大量的Hard Parse，
整體上拖延了執行時間。

客戶也懷疑 是 文件 2312911.1 所提到的 12.1 的 optimizer_adaptive_features 功能不夠完善導致出現問題。文件 2312911.1
提及，12.1 的 optimizer_adaptive_features 功能不夠完善，可以特殊處理，以達到12.2的效果(12.2中, optimizer_adaptive_
features 有所改善，被拆分成為了兩個引數)。

那麼，到底是不是這樣呢，客戶希望進一步進行分析調查。

從拿到了遷移前後的AWR來對比，發現了有趣的狀況：實際上從Top N SQL來看，遷移前的SQL文，遷移後執行時間其實都大幅度縮短了。

    ***遷移前環境
    ========================
    SQL ordered by Elapsed Time
       Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
       % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
       Total DB Time (s): 2,597  
       Captured SQL account for 58.8% of Total  <<<<<<<<<<<<Top 10 的SQL文，佔據了整體執行時間的 59%(1532秒)
       Total DB Time (s): 2,597
       Captured PL/SQL account for 0.3% of Total
    ========================

    ***遷移後(未追加 OPTIMIZER_FEATURES_ENABLE hint 的時候)
    ========================
    SQL ordered by Elapsed Time  ★
       Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
       % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
       %Total - Elapsed Time as a percentage of Total DB time
       %CPU - CPU Time as a percentage of Elapsed Time
       %IO - User I/O Time as a percentage of Elapsed Time
       Captured SQL account for 27.9% of Total DB Time (s): 1,771  <<<<<<<<<<<<Top 10 的SQL文，佔據了整體執行時間的 28%(500秒)
       Captured PL/SQL account for 1.3% of Total DB Time (s): 1,771
    ========================

從具體的top 10 SQL文執行時間上，也可以看出來：

    ++++++++++++++++++++++++++++++++++++++++++++++
    2ac8g6tagg67x  遷移後>>17,122 回執行  CPU Time 13.27s、Elapsed Time 139.03s  
                           遷移前>>21,018 回執行  CPU Time 16s、Elapsed Time 839s

    5mt3dyz3r6af8  遷移後>>425 回執行  CPU Time 25.28s、Elapsed Time 33.10s
                          遷移前>>509回執行  CPU Time 44s、Elapsed Time 105s

    7tjhsnk6ruw6m  遷移後>>165 回執行  CPU Time 16.67s、Elapsed Time 21.69s
                           遷移前>>165 回執行  CPU Time 25s、Elapsed Time 50s

    ......

    baq2zs9gns3co  遷移後>>51,730 回執行  CPU Time 9.92s、Elapsed Time 16.57s
                           遷移前>>67,66 4回執行  CPU Time 10s、Elapsed Time 26s
    ++++++++++++++++++++++++++++++++++++++++++++++

那麼，問題到底處在哪裡呢？ 我的猜測是： 雖然TopN 那些SQL文的執行時間減小了。但是還有很多執行很短暫的SQL文，由於動態執行
計劃調整，導致事件增加了。

這也很容易理解：

如果一條SQL語句的執行時間原本是200ms，如果動態執行計劃調整花5ms，使得因執行更好的執行計劃而較少了執行時間20ms,總體上來說
就是賺到了。

可是如果你一條小SQL執行語句，本來執行時間才20ms,如果動態執行計劃調整花5ms，使得因執行更好的執行計劃而較少了執行時間2ms,
反而執行時間增加了。

如果這條小SQL執行語句，反覆多次執行呢？那問題就惡化了。

就好比：雖說磨刀不誤砍柴功，但是如果每砍一個小樹杈，都要磨一次刀，那是不是有點浪費時間啊。

對於這個推測，客戶仍然想要了解更詳細的細節，那麼好吧，我們來看看ASH的情況：

遷移前

"In Hard Parse" ==> 15 行     "In Hard Parse" 的比例：37.5%
2018/03/12 15:26:36 --->  2018/03/12 15:37:25.693000000
SQL_ID: 30 個

遷移後

"In Hard Parse" ==> 252 行     "In Hard Parse" 的比例：76.6%
2018/03/20 11:33:50 --->  2018/03/20 12:25:58.591000000
SQL_ID: 292 個


遷移後的總體時間不但大幅度延長了，而且ASH中統計出來的sql_id 明顯增多。所以可以推測很多原本執行時間很短的sql語句，因為執行計劃
調整的原因，話費時間進行了 Hard Parse，所以當ASH取樣的時候，因為沒有執行完畢，更多的出現在ASH履歷中。

那麼，作為結論， 12c的執行計劃調整並不是適合所有sql文的，對效果不佳的語句，不妨新增 OPTIMIZER_FEATURES_ENABLE 進行微調。