1、并行引起的災禍

一大早，某網省兄弟告訴我，數據庫會話執行的SQL開啟了并行，導致負載很高，會話也高，查了半天，沒找到具體原因，也不知道該如何解決？

對于他的問題，我直接回應了：這還不清楚嗎？常見原因無非有以下兩個：

第一：對象開啟了并行（包括索引和表）

第二：SQL語句里面使用了PARALLEL的HINTS

現場兄弟說，都查了并沒有上面的情況，聽到他的回答，我首先對他查詢的方式持懷疑態度的，沒有設置并行度，也沒有加HINTS，執行的SQL怎么會并行執行呢？帶著這個疑問，我叫現場兄弟把查詢結果一一截圖給我，如下（文中案例都是事后補充）：

看到結果后我一時也有點摸不著頭腦，怎么回事？遇到問題我總是告訴自己要冷靜，不急。

2、層層推進，分析問題

是不是什么參數控制了？

SQL> show parameter parallel

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

fast_start_parallel_rollback         string      LOW

parallel_adaptive_multi_user         boolean     TRUE

parallel_automatic_tuning            boolean     FALSE

parallel_degree_limit                string      CPU

parallel_degree_policy               string      MANUAL

parallel_execution_message_size      integer     16384

parallel_force_local                 boolean     FALSE

parallel_instance_group              string     

parallel_io_cap_enabled              boolean     FALSE

parallel_max_servers                 integer     320

parallel_min_percent                 integer     0

parallel_min_servers                 integer     0

parallel_min_time_threshold          string      AUTO

parallel_server                      boolean     FALSE

parallel_server_instances            integer     1

parallel_servers_target              integer     128

parallel_threads_per_cpu             integer     2

recovery_parallelism                 integer     0

沒有發現可疑參數。

至此，表面排查的結果已經解決不了這個問題了，于是我讓現場找了一條正在并行的SQL ，手動執行，并收集一個10053事件trace，看看是否能有新發現。腳本如下 

很快現場提供了TRACE FILE文件給我，我優先看參數列表。

這時，我發現一個可疑的參數：parallel_query_default_dop  = 16

找到mos上關于該參數的相關信息，是一個默認并行度的參數，該參數值的算法如下：

DEFAULT DOP = cpu_count * parallel_threads_per_cpu* cluster_database_instances

我立刻問現場同事，執行的SQL在活動會話中體現的是不是16個并行進程。現場同事答復我，觀察到的基本就是。至此問題明朗起來了，執行的SQL使用了默認并行度執行，受參數parallel_query_default_dop控制。既然是默認的并行度，那也應該需要設置(如果不設置，默認是1)。于是我把前期的查詢驗證對象并行度是否開啟的SQL改造了下，具體如下（文中案例都是事后補充） 

 查詢結果截圖發出來，我就開心了，這里明顯有一個設置了并行度為DEFAULT（如果我們不設置就是1）的表和索引。然后確認了他們正是正在運行的sql中的對象。

3、問題解決

既然設置了默認并行度，那么只需要取消默認并行度即可，即執行如下SQL

--針對表

alter table table_name noparalle;

--針對索引

Alter index index_name noparallel;

于是我叫現場把對象并行度修改為1，再次執行該SQL，發現并行消失了，數據庫恢復了正常。

問題雖然解決了，但還有一個疑問沒有解開，什么情況下會設置的并行度為DEFUALT呢？正常創建索引和表都是1。

4、如何設置并行度為default

通過實踐發現如下2種方式可以實現并行度設置為DEFAULT。

1、創建表的時候指定:

    2、創建表之后可以修改

 小結：該問題解決第一個是思路 ,第二個是基本功要扎實。

1

背景如下：某網省采集中間庫從10.2.0.4升級到11.2.0.4（備注升級不是在老的機器上面直接升級，而是在新機器上面采用安裝遷移的方式）

升級完第二天現場找到我，說以前同步檔案數據的接口功能目前都運行非常慢（數據接口同步的方式采用的DBLINK），有時甚至無法正常運行完，影響檔案資料的同步，看來已經很嚴重了。

關鍵字：DB升級從10G升級到11G
我以前遇到過相關案例，覺得可能是升級帶來的執行計劃變化引起的。于是告知現場嘗試修改優化器參數即optimizer_features_enable改成10.2.0.4，可以在線改，立刻生效，腳本如下：
alter system set optimizer_features_enable='10.2.0.4' scope=both;
修改完成后，重新在執行同步檔案資料接口的任務看是否正常。
現場經過一番測試之后，問題沒有解決，看來老的經驗無法解決該問題。
好，接下來我們做了以下模擬測試：
該SQL的文本如下：

INSERT INTO EPCT.C_CUST_ADDR@EPEXDB
(CUST_ID,
CUST_ADDR,
PROVINCE_CODE,
CITY_CODE,
COUNTY_CODE,
STREET_CODE,
VILLAGE_CODE,
ROAD_CODE,
COMMUNITY_CODE,
PLATE_NO,
TYPE_CODE,
POSTALCODE,
CA_ID,
APP_NO)
SELECT A2.CUST_ID,
A2.CUST_ADDR,
A2.PROVINCE_CODE,
A2.CITY_CODE,
A2.COUNTY_CODE,
A2.STREET_CODE,
A2.VILLAGE_CODE,
A2.ROAD_CODE,
A2.COMMUNITY_CODE,
A2.PLATE_NO,
A2.TYPE_CODE,
A2.POSTALCODE,
A2.CA_ID,
''
FROM SGPM.C_CUST_ADDR A2
WHERE A2.CUST_ID=ANY
(SELECTA3.CUST_ID
FROM SGPM.C_CONS A5,
SGPM.R_CP_CONS_RELA A4,
SGPM.C_CUST A3
 WHERE A4.CONS_ID=A5.CONS_ID
 AND A4.CP_NO=:B1
 ANDA5.CUST_ID=A3.CUST_ID);
可以看到是用到DBLINK從A數據庫到B數據庫的插入語句，這個SQL發起端在A數據庫，也就是程序部署在A數據庫中，而該SQL實際執行端在B數據庫。雖然是往B數據庫插入數據，但是會派生一個查詢SQL到A數據庫取數。
針對INSERT INTO remote_table@dblink select * from local_table這種SQL執行端都會在遠端，不是本地，無法使用HINTS driving_site指定執行端。
2、然后會在A數據庫確認一下是否派生一個SQL，并且找到該SQLID
3、現場提供SQLID之后，我們可以獲取該sql執行的相關信息： 

select *from table(dbms_xplan.display_cursor('1ar4us01aj0hu',null,'ADVANCED'));

紅框里出現的字樣引起了我的注意，眼尖的DBA應該很快會發現其中的貓膩。

對的，這里調用了一個內部函數。這個函數的說明如下：

The internal Oracle function SYS_OP_C2C performs conversion
from one character set to another character set C(haracterSet)2C(haracterSet).

字符集之間的轉換。OK ，看到這里我問現場，新舊兩套B數據庫中字符集是什么? A數據庫字符集又是什么?

現場答復如下：

老的B數據庫字符集是utf-8

新的B數據庫字符集是zhs16gbk

而A數據庫字符集是utf-8

這個也就說明了，遷移到新采集中間庫之后性能急劇下降的原因找到了。

那么解決方式有如下2種方式：

第一修改字符集，保證源目標字符集一致。 

第二創建函數索引。

2