CONTEXT TOP 10 ISSUES

Question

제품 : ORACLE SERVER
작성날짜 : 2002-05-15
CONTEXT TOP 10 ISSUES
========================
Explanation
1. 프로시져 컴파일시 PLS-00201 과 "PL/SQL:Statement ignored" 에러의 발생하는
문제.
Stored procedure 컴파일시 다음과 같은 메시지가 나올 경우
PLS-00201 : identifiier 'CTXSYS.CTX_QUERY' must be declared
PL/SQL : Statement ignored
ctxsys 유저에서 해당 사용자에게 CTX_QUERY 에 대한 execute 권한을 준다.
-> grant execute on ctx_query to <user>;
2. UNIX에서 ps 명령으로 ctxsys 유저의 패스워드를 볼 수 있는 문제.
Unix에서 ps 명령으로 보면 다음과 같이 ctxsys 유저의 패스워드를
볼 수 있다.
/oracle/ora805/ctxsrv -user ctxsys/ctxsys -personality ...
이 경우 다음 password 파일을 사용하여 ctxsrv를 기동시키면 패스워드를
보이지 않게 할 수 있다.
passwordfile.txt 파일에 ctxsys/<ctxsys password> 형식으로 편집한 후
ctxsrv -personality QDM < passwordfile.txt &
3 Two Step Query 실행시 ORA-20000, DRG-10801, DRG10010 이 발생하는 문제.
     Two-Step ConText query를 실행하면 다음과 같이 error가 발생할 경우
     exec ctx_query.contains('PROJ_DESC_POLICY','customer','RESULT4');
     ERROR at line 1:
     ORA-20000: ConText error:
     DRG-10801: text query failed
     DRG-10010: REQUIRED COLUMN DOES NOT EXIST IN RESULT TABLE
     -> 이 error는 result table에 textkey2 column이 없기 때문에 나는 error
이다.
     composite textkey에 적절한 textkeyN를 가진 result table을 생성한다.
     예) exec ctx_ddl.create_policy(policy_name=> 'Proj_desc_policy',
     colspec=>'tprojects.column',textkey=> 'proj,title');
     Composite index가 'proj' 와 'title'의 두 column을 참조한다.
     create table result4(textkey,textkey2,score,conid);
4. 64k가 넘는 파일을 CTXLOAD로 올릴때 DRG-11514, DRG-11508, DRG-11505가
발생하는 문제.
64k가 넘는 파일을 ctxload로 올릴때 DRG-11514, DRG-11508, DRG-11505가
발생할 경우 ctxload command 에서 -longsize를 반드시 지정해 주어야 한다.
예) ctxload -user scott/tiger -table htmltable -load loadhtm2
-separate -longsize 100
5. Context Linguistics 서버 기동시 DRG-00100 및 "Server shutting down"
에러가 발생하는 문제.
설치할 때 context의 linguistic 설정이 완결되지 않아 발생한 문제로 다음
과같이 해결할 수 있다.
cd $ORACLE_HOME/ctx/admin
imp ctxsys/ctxsys file=ctxset.dmp full=y ignore=y
6. 다른 사용자가 생성한 테이블에 대해 select priviledge를 부여 받고도, 그
테이블에 대해 만든 policy로 structured query를 실행 할 경우 DRG-100[50801] 및
ORA-1031가 발생하는 문제.
select priviledge 이외에 grant option을 받아야 한다.
grant select on <tablename> to <사용자명> with grant option;
7. 다른 사용자가 생성한 테이블에 만든 policy로 질의 실행시 ORA-20000,
DRG-10801, DRG10502, ORA-06512 가 발생하는 문제.
ERROR at line 1:
ORA_20000: Context error:
DRG-10801: text query failed
DRG-10502: policy 'policy name' does not exist
ORA-06512: at "CTXSYS.DRUE", line 180
ORA-06512: at "CTXSYS.CTX_QUERY", line 1417
ORA-06512: at line 1
이와 같은 에러 메시지가 뜰 경우 policy 및 index가 정상적으로 생성이
되었는지, 그리고 대상 table에 대한 select 권한을 부여 받았는지 확인해 본
다.
8. Policy 생성시 ORA-200000 과 DRG-10503 이 발생하는 문제.
exec ctx_ddl.create_policy('POLICY_NAME', 'table.tablecolumn');
ORA-20000
DRG-10503 suitable textkey not found
이와 같은 에러가 발생할 경우 해당 테이블에 primary key를 지정해 주어야
한다.
alter table <table_name> add constraint primary key (column_name);
9. Context 사용자를 cascade 옵션을 사용해서 drop 한 후 context server를
기동시킬 때 DRG-50301,ORA-20000, DRG-11000, ORA-02292 가 발생하면서 기동이 되지 않는 문제.
Context server 기동시 다음과 같은 에러메시지가 나오는 것은 사용자를
cascade option으로 drop 시켰기 때문이다.
DRG-50301 Server error reading request queue
ORA-20000 Context error
DRG-11000 failed to perform recovery for a server or client
ORA-02292 integrity constraint (%s.%s) violated -child record found
이것은 drop 된 context 사용자의 index, policy, preference가 계속 존재 하기 때문이다.
해결책은 drop된 사용자와 동일한 이름으로 user를 만들고, 기존에 부여된
role (ctxsys, ctxapp, ctxuser) 를 부여해 준 후, index, policy,
reference를 순서대로 삭제해 주면 된다.
10. Policy 생성시 DRG-10537, ORA-06512 발생하는 문제.
exec ctx_ddl.create_policy('POLICY_NAME', 'tablename.colname');
DRG-10537 textkey <col_name> length of 80 exceeds limit
ORA-6512 at ctxsys.drue, line 110
ORA-6512 at ctxsys.drue, line 833
이 문제는 textkey가 시스템상에서 한계치인 64k를 넘어 설 경우 발생한다.
exec ctx_ddl.create_policy(policy_name => 'POLICYNAME',
colspec => 'tablename.colname', textkey => 'tablename.keycolname')
과 같이 명시적으로 primary key 컬럼을 지정해 주어 unique constraint를
가진 모든컬럼이 textkey에 포함되지 않도록 해 본다.
Reference Ducumment
---------------------

Answer 1

There is nothing like Top issues with it!!!!
If you need to use DBlinks then you ought to use it, thats simple.
The only thing is that you need to be aware of some facts:
1) You should get access to the remote database for creating the DB links. Sometimes remote databases are goverened by different SLAs and hence its diffucult to get access to userid/password.
2) Evaluate carefully before creating public database links, that might expose your remote database to all the local database accounts without your knowledge.
3) With DB links comes into picture districuted transactions and hence expect execution plans etc behaving different in comparison to sqls accessing the same DB.
4) Also be ready to view more DBA_2pc_pending and DBA_2pc_neighbors DD views, since due to any instablity in network between local and remote DB there might be in-doubt transactions.
5) when clonding the PROD DB to test database, make sure to wipe out the dblinks so that nothing from test points to prod environment.