Skip to Main Content
  • Questions
  • After import Full DB, how to get indexed column information from dictionaries rather than using ctx_report with describe_index

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Pauline.

Asked: October 09, 2013 - 3:56 pm UTC

Last updated: November 01, 2013 - 5:53 pm UTC

Version: 11.2.0

Viewed 10K+ times! This question is

You Asked

Tom,
When we do upgrade DB from 10g to 11g, we used expdp/impdp to upgrade. Now all oracle text are working fine. But we lost the information previously stored in CTX_Sections and other CTX_* dictionary view. For example

CTXSYS@prd1 > select count(*) from ctx_sections;

COUNT(*)
----------
0

--Core is the owner of Oracle text indexes
CORE@prd1 > select count(*) from ctx_sections;

COUNT(*)
----------
0

Now I need to query indexed columns in Oracle text from dictionary. I may run CTX_REPORT.DESCRIBE_INDEX with specified context index name
to get the information for which columns to be indexed in Oracle text index, for example,
CORE@prd1 > set long 3000
CORE@prd1 > select ctx_report.DESCRIBE_INDEX('CORE.ARTISTS_CTX') from dual;

The output for the indexed columns will display as

CTX_REPORT.DESCRIBE_INDEX('ARTISTS_CTX')
--------------------------------------------------------------------------------
field section: ARTIST_NM
section tag: ARTIST_NM
visible: Y
field id: 16
field section: FIRST_NM
section tag: FIRST_NM
visible: Y
field id: 17

But I want to know is any other way to easily get the results just for the output like

column_name index name
-----------------------------------------------------------
ARTIST_NM ARTISTS_CTX
FIRST_NM ARTISTS_CTX

The view of dba_ind_columns only have the dummy column inforamtion for the text index.

ORACLE@prd1 > select column_name||' -- '||index_name from dba_ind_columns where index_name ='ARTISTS_CTX' and index_owner='CORE';

COLUMN_NAME||'--'||INDEX_NAME
--------------------------------------------------------------------------------
SEARCH_COLUMN -- ARTISTS_CTX

We have many Oracle TEXT indexes in the database and need to have a clear report to show which TEXT index has what columns to be indexed.
Please help.
Thank very much.
Pauline





Tom, our issue was caused by full upgrade DB from 10g to 11g. We created shell DB in new server with 11g new version and then did full import. The CTXSYS schema was not imported to 11g DB and no error in the log. So in my case, if now I do in same DB: exec all of the context calls I need to demonstrate with
create table ...
insert a row
commit;
query to show catalog data,
expdp .........
drop table ...
impdp ....
query will not show missing data. But if I import to another database,then query will show missing data. Please see my test codes which in code section
--In 11.2.0.2.0 DB dev1
create table dbacode.test (ARTIST_ID number not null, artist_nm varchar2(50),first_nm varchar2(50));
insert into dbacode.test values(1,'John Constable','John');
insert into dbacode.test values(2,'Roy Lichtenstein','Roy');
insert into dbacode.test values(3,'Jackson Pollock','Jackson');
insert into dbacode.test values(4,'Alexander Calder','Alexander');
insert into dbacode.test values(5,'John P. Benson','John; P.');
commit;
select * from test;
alter table dbacode.test add SEARCH_COLUMN  CHAR(1);

exec ctx_ddl.create_preference('test_mcds', 'MULTI_COLUMN_DATASTORE');
exec ctx_ddl.set_attribute( 'test_mcds','columns','artist_nm,first_nm');

--CTX_Preferences and CTX_Preference_values will have entry for 'TEST_MCDS'
col PRV_VALUE for a10
set linesize 120
select * from ctx_preference_values where prv_preference like 'TEST%';
col PRE_VALUE for a10
select * from ctx_preferences  where pre_name like 'TEST%';


begin
  ctx_ddl.create_section_group('test_secgrp','BASIC_SECTION_GROUP');
  ctx_ddl.add_field_section('test_secgrp','ARTIST_NM','ARTIST_NM',TRUE);
  ctx_ddl.add_field_section('test_secgrp','FIRST_NM','FIRST_NM',TRUE);
end;
/

--Now may see field info in CTX_SECTIONS & ctx_section_groups
COLUMN SEC_OWNER FORMAT a10
COLUMN SEC_SECTION_GROUP FORMAT a30
COLUMN SEC_TYPE FORMAT a10
COLUMN SEC_NAME FORMAT a30
COLUMN SEC_TAG FORMAT a30
set linesize 200
SELECT SEC_SECTION_GROUP,SEC_OWNER,SEC_TYPE,SEC_ID,SEC_NAME,SEC_TAG 
FROM CTX_SECTIONS
WHERE SEC_SECTION_GROUP=UPPER('test_secgrp')
AND SEC_NAME=SEC_TAG 
ORDER BY 1,2,3,4;

select * from ctx_section_groups where sgp_name='TEST_SECGRP';


--Create CTX
CREATE INDEX dbacode.TEST_CTX ON TEST (SEARCH_COLUMN)
   INDEXTYPE IS CTXSYS.CONTEXT  
   PARAMETERS ('datastore test_mcds 
              section group test_secgrp 
               sync (on commit)') ;

--Query by CTX
select artist_nm,first_nm from test
where contains
(search_column,'John within artist_nm
or
Roy within first_nm',1)>0;

set long 200000000
set pagesize 0
set head off
set ECHO OFF FEEDBACK OFF
set linesize 400
set trimspool on
col SCRIPT format a300 word_wrapped

SELECT CTX_REPORT.CREATE_INDEX_SCRIPT('test_ctx') from dual;

--expdp
expdp directory=DB TABLES=TEST  dumpfile=DBACODE.TEST.2013-10-10.dmp logfile=expdp.DBACODE.TEST.2013-10-10.log
/*
Username: dbacode
Password: xxxxxxx
*/

--Drop table in dev1
drop table dbacode.test;
--Query again after drop table
COLUMN SEC_OWNER FORMAT a10
COLUMN SEC_SECTION_GROUP FORMAT a30
COLUMN SEC_TYPE FORMAT a10
COLUMN SEC_NAME FORMAT a30
COLUMN SEC_TAG FORMAT a30
set linesize 200
SELECT SEC_SECTION_GROUP,SEC_OWNER,SEC_TYPE,SEC_ID,SEC_NAME,SEC_TAG 
FROM CTX_SECTIONS
WHERE SEC_SECTION_GROUP=UPPER('test_secgrp')
AND SEC_NAME=SEC_TAG 
ORDER BY 1,2,3,4;

select * from ctx_section_groups where sgp_name='TEST_SECGRP';
col PRV_VALUE for a10
set linesize 120
select * from ctx_preference_values where prv_preference like 'TEST%';
col PRE_VALUE for a10
select * from ctx_preferences  where pre_name like 'TEST%';

--query results show that information still there in DB dev1

--impdp
impdp directory=DB TABLES=TEST  dumpfile=DBACODE.TEST.2013-10-10.dmp logfile=impdp.DBACODE.TEST.2013-10-10.log

----Query by CTX after impdp to DB dev1
select artist_nm,first_nm from test
where contains
(search_column,'John within artist_nm
or
Roy within first_nm',1)>0; 

--query ater impdp to DB dev1
COLUMN SEC_OWNER FORMAT a10
COLUMN SEC_SECTION_GROUP FORMAT a30
COLUMN SEC_TYPE FORMAT a10
COLUMN SEC_NAME FORMAT a30
COLUMN SEC_TAG FORMAT a30
set linesize 200
SELECT SEC_SECTION_GROUP,SEC_OWNER,SEC_TYPE,SEC_ID,SEC_NAME,SEC_TAG 
FROM CTX_SECTIONS
WHERE SEC_SECTION_GROUP=UPPER('test_secgrp')
AND SEC_NAME=SEC_TAG 
ORDER BY 1,2,3,4;

select * from ctx_section_groups where sgp_name='TEST_SECGRP';
col PRV_VALUE for a10
set linesize 120
select * from ctx_preference_values where prv_preference like 'TEST%';
col PRE_VALUE for a10
select * from ctx_preferences  where pre_name like 'TEST%';

--!!! The information in CTX_* are not removed after impdp the table in same database

===== ** Now import to another database - ucd1 - same version 11.2.0.2.0
-- Query before impdp to ucd1
SELECT * from CTX_SECTIONS;  
select * from ctx_section_groups where sgp_name='TEST_SECGRP';
col PRV_VALUE for a10
set linesize 120
select * from ctx_preference_values where prv_preference like 'TEST%';
col PRE_VALUE for a10
select * from ctx_preferences  where pre_name like 'TEST%';

--All above queries return 'no rows selected'
impdp directory=DB TABLES=TEST   dumpfile=DBACODE.TEST.2013-10-10.dmp logfile=impd_to_ucd1.DBACODE.TEST.2013-10-10.impdp.log

----Query by CTX index after impdp to ucd1
select artist_nm,first_nm from test
where contains
(search_column,'John within artist_nm
or
Roy within first_nm',1)>0; 

---Query catalog after impdp to ucd1

SELECT * from CTX_SECTIONS;  
select * from ctx_section_groups where sgp_name='TEST_SECGRP';
col PRV_VALUE for a10
set linesize 120
select * from ctx_preference_values where prv_preference like 'TEST%';
col PRE_VALUE for a10
select * from ctx_preferences  where pre_name like 'TEST%';

--!! Now all return 'no rows selected'

set long 3000
select ctx_report.describe_index('TEST_CTX') from dual;
--The report has the 2 fields which indexed in oracle text.
Please let me know if you may see my update clearly.

and Tom said...

I talked with Roger Ford, resident expert on all things context, and he says:

<quote>

When you create an index, you might do something like:

ctx_ddl.create_preference('mylexer', 'BASIC_LEXER')
ctx_ddl.set_attribute('mylexer', 'PRINTJOINS', '-.')
create index myindex on mytable (mycol) indextype is ctxsys.context parameters ('mylexer')


At that point, our lexer preference (the fact that we want hyphen and period to join words together) is copied into the index. We can subsequently drop or modify the preference named "mylexer", and it will make no difference to the way the index works.

When we export the index, the copied-in preference is copied with it. If the index is rebuilt (though not if it's dropped and recreated) then join characters will remain as they are.

So to suggest that we don't export the preference is incorrect. We do export it, as metadata inside the index.

What we DON'T export is the current preference settings which are stored in various tables in the CTXSYS schema. If you tried to re-run the "create index" statement on the import database, then it would fail because the preference doesn't exist - just the same as it would if we had dropped the preference subsequent to creating the index on the original database.

The workaround for this is to run CTX_REPORT.CREATE_INDEX_SCRIPT. That looks at the metadata for an index (which might be the one you imported) and generates all the necessary SQL to recreate equivalent preferences as they were when the index was originally created.

There might be scope for some utility function to export the current set of preference settings from the CTXSYS schema. We wouldn't want to export the entire CTXSYS schema, as this contains all the copied-in metadata as well as the preference settings. But perhaps it would be useful to customers to have the ability to copy all the current settings to a new db without having to run scripts to recreate them. This is not something we currently plan to do, but it could we worth discussing.

- Roger

</quote>

so basically - the metadata for the context objects you created (preferences and such) is copied into the index definition itself. You can change the preferences - but that won't affect any existing index, you would have to drop and recreate them. What that means is - if we used the preferences to create the new index - you could easily end up with an entirely different index.

So, their approach is to copy over the index as it exists - but leave behind the other context bits of metadata. The developers to acknowledge that there could be some usefulness to having the preferences and so on get copied over and are now thinking about it....


Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Explained very detail

Pauline, November 26, 2013 - 2:26 am UTC

Tom,
I was out of contry and unable to check this website.
Thanks to you and Roger Ford for providing very detailed explanation and possible approach. Especially I am glad that "The developers to acknowledge that there could be some usefulness to having the preferences and so on get copied over and are now thinking about it....". I hope in later release we won't have such issue.


More to Explore

Data Pump

All of the database utilities including Data Pump are explained in the Utilities guide.