關於desc的一個奇怪問題及分析(r2第18天)
在平時的工作中，desc這個命令可謂短小精悍，可以很方便的查看錶結構和not null的情況。 今天在生產環境中碰到一個有些奇怪的desc問題。 首先是資料遷移組說有一個表的constraint丟了。但是在master中有。 這種問題有兩種可能，一種就是constraint確實丟了。 另一種可能性就是建立的constraint的問題，可以參見： not null constraint和check constriant的問題及分析 http://blog.itpub.net/23718752/viewspace-1154073/ 先來檢視master中的情況，desc確實沒有問題。 ------details from master
********** TABLE columns INFO *****************
COLUMN_ID COLUMN_NAME DATA_TYPE DATA_LENGTH NULLABLE DATA_DEFAULT
---------- ------------------------------ --------------- ----------- ---------- --------------------
1 ID NUMBER(12,0) 22 N
2 SYS_CREATION_DATE DATE 7 N
3 SYS_UPDATE_DATE DATE 7 Y
4 OPERATOR_ID NUMBER(9,0) 22 Y
5 APPLICATION_ID CHAR(6) 6 Y
6 DL_SERVICE_CODE CHAR(5) 5 Y
7 DL_UPDATE_STAMP NUMBER(4,0) 22 Y
8 TYPE VARCHAR2(30) 30 N
9 CODE VARCHAR2(60) 60 N
10 LANGUAGE VARCHAR2(30) 30 N
11 DESCRIPTION VARCHAR2(180) 180 Y
12 BE NUMBER(9,0) 22 N 0
********** CONSTRAINTS DETAILS INFO *****************
COLUMN_NAME CONSTRAINT_NAME C SEARCH_CONDITION DEFERRED DEFERRABLE RELY INDEX_NAME
-------------------- ------------------------------ - ----------------------------------- --------- -------------- ---- ------------------------------
BE AR1_GENE_BE_NN C "BE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
LANGUAGE AR1_GENE_LANGUAGE_NN C "LANGUAGE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
CODE AR1_GENE_CODE_NN C "CODE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
TYPE AR1_GENE_TYPE_NN C "TYPE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
SYS_CREATION_DATE AR1_GENE_SYS_CREATION_DATE_NN C "SYS_CREATION_DATE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
ID AR1_GENE_ID_NN C "ID" IS NOT NULL IMMEDIATE NOT DEFERRABLE
TYPE AR1_GENERIC_CODES_PK P IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_PK
CODE AR1_GENERIC_CODES_PK P IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_PK
LANGUAGE AR1_GENERIC_CODES_PK P IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_PK
BE AR1_GENERIC_CODES_PK P IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_PK
ID AR1_GENERIC_CODES_1UQ U IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_1UQ
11 rows selected.
但是在有問題的使用者下檢視，desc確實有問題
---from issue db account
COLUMN_ID COLUMN_NAME DATA_TYPE DATA_LENGTH NULLABLE DATA_DEFAULT
---------- ------------------------------ --------------- ----------- ---------- --------------------
1 ID NUMBER(12,0) 22 Y
2 SYS_CREATION_DATE DATE 7 Y
3 SYS_UPDATE_DATE DATE 7 Y
4 OPERATOR_ID NUMBER(9,0) 22 Y
5 APPLICATION_ID CHAR(6) 6 Y
6 DL_SERVICE_CODE CHAR(5) 5 Y
7 DL_UPDATE_STAMP NUMBER(4,0) 22 Y
8 TYPE VARCHAR2(30) 30 Y
9 CODE VARCHAR2(60) 60 Y
10 LANGUAGE VARCHAR2(30) 30 Y
11 DESCRIPTION VARCHAR2(180) 180 Y
12 BE NUMBER(9,0) 22 Y 0
但是奇怪的是constraint都在。
********** CONSTRAINTS DETAILS INFO *****************
COLUMN_NAME CONSTRAINT_NAME C SEARCH_CONDITION DEFERRED DEFERRABLE RELY INDEX_NAME
-------------------- ------------------------------ - ----------------------------------- --------- -------------- ---- ------------------------------
BE AR1_GENE_BE_NN C "BE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
LANGUAGE AR1_GENE_LANGUAGE_NN C "LANGUAGE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
CODE AR1_GENE_CODE_NN C "CODE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
TYPE AR1_GENE_TYPE_NN C "TYPE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
SYS_CREATION_DATE AR1_GENE_SYS_CREATION_DATE_NN C "SYS_CREATION_DATE" IS NOT NULL IMMEDIATE NOT DEFERRABLE
ID AR1_GENE_ID_NN C "ID" IS NOT NULL IMMEDIATE NOT DEFERRABLE
TYPE AR1_GENERIC_CODES_PK P IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_PK
CODE AR1_GENERIC_CODES_PK P IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_PK
LANGUAGE AR1_GENERIC_CODES_PK P IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_PK
BE AR1_GENERIC_CODES_PK P IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_PK
ID AR1_GENERIC_CODES_1UQ U IMMEDIATE NOT DEFERRABLE AR1_GENERIC_CODES_1UQ
那就排除了constraint丟失的情況了，檢視是不是not null constraint的問題。
得到了對應的ddl語句,檢視constraint是沒有問題的。但是可以看到有一個奇怪的地方，就是constraint是disable的。
CREATE TABLE "xxxx"
("ID" NUMBER(12, 0) CONSTRAINT "AR1_GENE_ID_NN" NOT NULL DISABLE,
"SYS_CREATION_DATE" DATE CONSTRAINT "AR1_GENE_SYS_CREATION_DATE_NN" NOT NULL DISABLE,
"SYS_UPDATE_DATE" DATE,
"OPERATOR_ID" NUMBER(9, 0),
"APPLICATION_ID" CHAR(6),
"DL_SERVICE_CODE" CHAR(5),
"DL_UPDATE_STAMP" NUMBER(4, 0),
"TYPE" VARCHAR2(30) CONSTRAINT "AR1_GENE_TYPE_NN" NOT NULL DISABLE,
"CODE" VARCHAR2(60) CONSTRAINT "AR1_GENE_CODE_NN" NOT NULL DISABLE,
"LANGUAGE" VARCHAR2(30) CONSTRAINT "AR1_GENE_LANGUAGE_NN" NOT NULL DISABLE,
"DESCRIPTION" VARCHAR2(180),
"BE" NUMBER(9, 0) CONSTRAINT "AR1_GENE_BE_NN" NOT NULL DISABLE)
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE (INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "DATAS01" LOGGING NOCOMPRESS
/
檢視這個使用者下constraint不為ENABLED的情況，這樣可以檢視還有沒有類似的問題存在。但是如下的查詢有些矛盾。很是蹊蹺。
SQL> select constraint_name,status from user_constraints where status!='ENABLED';
no rows selected
檢視有問題的表對應的constraint,檢視constraint的狀態，顯示確實enabled.
SQL> select constraint_name,status from user_constraints where table_name='AR1_GENERIC_CODES';
CONSTRAINT_NAME STATUS
------------------------------ --------
AR1_GENE_ID_NN ENABLED
AR1_GENE_SYS_CREATION_DATE_NN ENABLED
AR1_GENE_TYPE_NN ENABLED
AR1_GENE_CODE_NN ENABLED
AR1_GENE_LANGUAGE_NN ENABLED
AR1_GENE_BE_NN ENABLED
AR1_GENERIC_CODES_PK ENABLED
AR1_GENERIC_CODES_1UQ ENABLED
所以，從以上的排查，發現這是一個數據字典中的資訊不匹配造成的，應該是oracle的一個bug,檢視metalink沒有找到相關的bug id.
但是問題不管怎麼樣都得解決，如果這是一個bug,就不能直接在生產中修改，萬一出現嚴重問題就得不償失了。
我採用的步驟如下：
從生產的備份庫中匯出這個表的dump，然後匯入另外一個測試環境中，可以看到在測試環境這個問題可以復現。
修復之前使用desc檢視。
SQL> desc ar1_generic_codes
Name Null? Type
----------------------------------------- -------- ----------------------------
ID NUMBER(12)
SYS_CREATION_DATE DATE
SYS_UPDATE_DATE DATE
OPERATOR_ID NUMBER(9)
APPLICATION_ID CHAR(6)
DL_SERVICE_CODE CHAR(5)
DL_UPDATE_STAMP NUMBER(4)
TYPE NOT NULL VARCHAR2(30)
CODE NOT NULL VARCHAR2(60)
LANGUAGE NOT NULL VARCHAR2(30)
DESCRIPTION VARCHAR2(180)
BE NOT NULL NUMBER(9)
SQL> alter table ar1_generic_codes enable constraint AR1_GENE_ID_NN;
Table altered.
修復後，使用desc再次檢視。
SQL> desc ar1_generic_codes
Name Null? Type
----------------------------------------- -------- ----------------------------
ID NOT NULL NUMBER(12)
SYS_CREATION_DATE DATE
SYS_UPDATE_DATE DATE
OPERATOR_ID NUMBER(9)
APPLICATION_ID CHAR(6)
DL_SERVICE_CODE CHAR(5)
DL_UPDATE_STAMP NUMBER(4)
TYPE NOT NULL VARCHAR2(30)
CODE NOT NULL VARCHAR2(60)
LANGUAGE NOT NULL VARCHAR2(30)
DESCRIPTION VARCHAR2(180)
BE NOT NULL NUMBER(9)
如果再進一步檢視這個問題，很有可能是在做goldengate同步的時候引入的。這個表在使用goldengate同步後沒有做任何的結構變化。
但是要驗證，需要得到更多的細節來驗證。