Linguistic index with LIKE + LOWER

Hi,
It seems that Oracle 11.2.0.1.0 is not able to use linguistic index when using the LIKE operator + LOWER function...
ALTER SESSION SET NLS_COMP='LINGUISTIC';
ALTER SESSION SET NLS_SORT='FRENCH_AI';
CREATE INDEX test_fai_idx
ON mytable(NLSSORT(LOWER(somefield), 'NLS_SORT=FRENCH_AI'));
SELECT *
FROM mytable
WHERE LOWER(somefield) LIKE 'gue%';
-- Table access FULL
DROP INDEX test_fai_idx;
ALTER SESSION SET NLS_COMP='BINARY';
CREATE INDEX test_bin_idx
ON mytable(LOWER(somefield));
SELECT *
FROM mytable
WHERE LOWER(somefield) LIKE 'gue%';
-- Index Range Scan
Questions:
-Will an upgrade to 11.2.0.2, 11.2.0.3 or 11.2.0.4 could solve that problem? (if anyone of you who have access to such a db and could make the test and report the result here, that will be much appreciated)
-Other ideas to help me?
I understand that using LOWER + AI seem strange since AI means accent-insensitive AND case-insensitive but, the software which run on the db use LOWER in all his SQL...
Thanks.
Paulo

create table test (nid number, name varchar2(30))
insert into test values(1, 'hügo')
ALTER SESSION SET NLS_COMP='LINGUISTIC';
ALTER SESSION SET NLS_SORT='FRENCH_AI';
select
from test
where
lower(name) like 'hug%'
no data found, full scan
create index idx_t on test(lower(name))
select
from test
where
lower(name) like 'hug%'
no data found, index range scan
drop index idx_t
create index idx_t on test(nlssort(lower(name), 'NLS_SORT=FRENCH_AI'))
select
from test
where
lower(name) like 'hug%'
no data found, full scan
Why should the index be used? You are looking for lower(name) but nlssort(lower(name), 'NLS_SORT=FRENCH_AI') indeed is something totally different:
select
nlssort(lower(name), 'NLS_SORT=FRENCH_AI') s
from test
S
3773325A000202020200
since
select
nlssort('hug', 'NLS_SORT=FRENCH_AI') s
from test
is
S
3773320002020200
you might recongize that it is not possible to do a like with nlssort.

Similar Messages

  • My website looks fine in other browsers but on firefox it comes up like an index with the title first and on the second line it says skip to content. Can this be fixed?

    When I look at my website it loads up as an index with the heading on the top line and then a link saying "skip to content" and then the navigation is in bullet points. I have downloaded the latest version of firefox and this has not improved the situation. The website looks fine in other browsers.

    Make sure that you do not block the CSS files on that page.
    Reload web page(s) and bypass the cache.
    * Press and hold Shift and left-click the Reload button.
    * Press "Ctrl + F5" or press "Ctrl + Shift + R" (Windows,Linux)
    * Press "Cmd + Shift + R" (MAC)
    Start Firefox in <u>[[Safe Mode]]</u> to check if one of the extensions is causing the problem (switch to the DEFAULT theme: Firefox (Tools) > Add-ons > Appearance/Themes).
    *Don't make any changes on the Safe mode start window.
    *https://support.mozilla.com/kb/Safe+Mode

  • Case Insensitive Search coupled with "LIKE" operator.

    Greetings All, I am running Oracle 11gR1 RAC patchet 25 on Windows X64.
    This db supports and application that requires case insensitive searches.
    Because there are a few entry points into the db I created an "after login" trigger:
    CREATE OR REPLACE TRIGGER MyAppAfterLogon_TRGR
    AFTER LOGON
    ON DATABASE
    DECLARE
    vDDL VARCHAR2(200) := 'alter session set nls_comp=''linguistic''';
    vDDL2 VARCHAR2(200) := 'alter session set nls_sort=''binary_ci''';
    BEGIN
    IF ((USER = 'MyAppUSER') OR(USER = 'MyAppREPORTINGUSER')) THEN
    EXECUTE IMMEDIATE vDDL;
    EXECUTE IMMEDIATE vDDL2;
    END IF;
    END MyAppAfterLogon_TRGR;
    This ensures that everyone connecting to the DB via any mechanism will automatically have case insensitive searches.
    Now, to optimize the know queries I created the standard index to support normal matching queries:
    select * from MyTable where Name = 'STEVE';
    The index looks like:
    CREATE INDEX "CONTACT_IDX3 ON MYTABLE (NLSSORT("NAME",'nls_sort=''BINARY_CI'''))
    This all works fine, no issues.
    The problem is when I write a query that uses the "LIKE" operator:
    select * from MyTable where Name like 'STEV%';
    I get back the record set I expect. However, my index is not used? I can't for the life of me get this query to use an index.
    The table has about 600,000 rows and I have run gather schema stats.
    Does anyone know of any issues with case insensitive searches and the "LIKE" clause?
    Any and all help would be appreciated.
    L

    I think there is issue with your logon trigger :
    "IF ((USER = 'MyAppUSER') OR(USER = 'MyAppREPORTINGUSER')) THEN"
    it should be :
    IF UPPER(USER) = 'MYAPPUSER' OR UPPER(USER) = 'MYAPPREPORTINGUSER' THEN
    because user name stored in Upper case. Check and try.
    HTH
    Girish Sharma

  • Error when creating index with parallel option on very large table

    I am getting a
    "7:15:52 AM ORA-00600: internal error code, arguments: [kxfqupp_bad_cvl], [7940], [6], [0], [], [], [], []"
    error when creating an index with parallel option. Which is strange because this has not been a problem until now. We just hit 60 million rows in a 45 column table, and I wonder if we've hit a bug.
    Version 10.2.0.4
    O/S Linux
    As a test I removed the parallel option and several of the indexes were created with no problem, but many still threw the same error... Strange. Do I need a patch update of some kind?

    This is most certainly a bug.
    From metalink it looks like bug 4695511 - fixed in 10.2.0.4.1

  • Performance - composite index with 'OR' in 'WHERE' clause

    I have a problem with the performance of the following query:
    select /*+ index_asc(omschact oma_index1) */ knr, projnr, actnr from omschact where ((knr = 100 and actnr > 30) or knr > 100)
    and rownum = 1;
    (rownum used only for test purpose)
    index:
    create index on omschact (knr, projnr);
    Execution plan:
    Id Operation
    0 SELECT STATEMENT
    1 COUNT STOPKEY
    2 TABLE ACCESS BY INDEX ROWID
    3 INDEX FULL SCAN
    If I'm correct, the 'OR' in the 'WHERE' clause is responsible for the INDEX FULL SCAN, what makes the query slow.
    A solution would be then to separate the 'WHERE' clause in 2 separate select's (1 with 'knr = 100 and actnr > 30' and 1 with 'knr > 100' and combine the results with a UNION ALL.
    Since it's necessary to have all rows in ascending order (oma_index1) I still have to use an ORDER BY to make sure the order of the rows is correct. This results again in a (too) low performance.
    Another solution that does the trick is to create an index with the 2 fields (knr, projnr) concatenated and to use the same in the 'WHERE' clause:
    create index oma_index2 on omschact (knr || projnr);
    select /*+ index_asc(omschact oma_index2) */ knr, projnr, actnr from omschact where (knr || projnr) > 10030;
    I just can't believe this work-around is the only solution, so I was hoping that someone here knows of a better way to solve this.

    padders,
    I'll give the real data instead of the example. The index I really use consists of 4 fields. In this table the fields are just numbers, but in other tables I need to use char-fields in indexes, so that's why I concatenate instead of using formula's (allthough I would prefer the latter).
    SQL> desc omschact
    Name Null? Type
    KNR NOT NULL NUMBER(8)
    PROJNR NOT NULL NUMBER(8)
    ACTNR NOT NULL NUMBER(8)
    REGELNR NOT NULL NUMBER(3)
    REGEL CHAR(60)
    first methode:
    SQL> create index oma_key_001(knr,projnr,actnr,regelnr);
    Index created.
    SQL> select /*+ index_asc(omschact oma_key_001) */ * from omschact where
    2 (knr > 100 or
    3 (knr = 100 and projnr > 30) or
    4 (knr = 100 and projnr = 30 and actnr > 100000) or
    5 (knr = 100 and projnr = 30 and actnr = 100000 and regelnr >= 0));
    Execution Plan
    Plan hash value: 1117430516
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 11M| 822M| 192K (1)| 00:38:26 |
    | 1 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 11M| 822M| 192K (1)| 00:38:26 |
    |* 2 | INDEX FULL SCAN | OMA_KEY_001 | 11M| | 34030 (1)| 00:06:49 |
    Predicate Information (identified by operation id):
    2 - filter("KNR">100 OR "KNR"=100 AND "PROJNR">30 OR "KNR"=100 AND "PROJNR"=30
    AND "ACTNR">100000 OR "ACTNR"=100000 AND "KNR"=100 AND "PROJNR"=30 AND
    "REGELNR">=0)
    second method (same index):
    SQL> select * from (
    2 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr > 100
    3 union all
    4 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr = 100 and projnr > 30
    5 union all
    6 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr = 100 and projnr = 30 and actnr > 100000
    7 union all
    8 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr = 100 and projnr = 30 and actnr = 100000 and regelnr > 0)
    9 order by knr, projnr, actnr, regelnr;
    Execution Plan
    Plan hash value: 292918786
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 11M| 1203M| | 477K (1)| 01:35:31 |
    | 1 | SORT ORDER BY | | 11M| 1203M| 2745M| 477K (1)| 01:35:31 |
    | 2 | VIEW | | 11M| 1203M| | 192K (1)| 00:38:29 |
    | 3 | UNION-ALL | | | | | | |
    | 4 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 11M| 822M| | 192K (1)| 00:38:26 |
    |* 5 | INDEX RANGE SCAN | OMA_KEY_001 | 11M| | | 33966 (1)| 00:06:48 |
    | 6 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 16705 | 1272K| | 294 (1)| 00:00:04 |
    |* 7 | INDEX RANGE SCAN | OMA_KEY_001 | 16705 | | | 54 (0)| 00:00:01 |
    | 8 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 47 | 3666 | | 4 (0)| 00:00:01 |
    |* 9 | INDEX RANGE SCAN | OMA_KEY_001 | 47 | | | 3 (0)| 00:00:01 |
    | 10 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 1 | 78 | | 4 (0)| 00:00:01 |
    |* 11 | INDEX RANGE SCAN | OMA_KEY_001 | 1 | | | 3 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    5 - access("KNR">100)
    7 - access("KNR"=100 AND "PROJNR">30)
    9 - access("KNR"=100 AND "PROJNR"=30 AND "ACTNR">100000)
    11 - access("KNR"=100 AND "PROJNR"=30 AND "ACTNR"=100000 AND "REGELNR">0)
    third method:
    SQL> create index oma_test(to_char(knr,'00000000')||to_char(projnr,'00000000')||to_char(actnr,'00000000')||to_char(regelnr,'000'));
    Index created.
    SQL> select /*+ index_asc(omschact oma_test) */ * from omschact where
    2 (to_char(knr,'00000000')||to_char(projnr,'00000000')||
    3 to_char(actnr,'00000000')||to_char(regelnr,'000')) >=
    4 (to_char(100,'00000000')||to_char(30,'00000000')||
    5* to_char(100000,'00000000')||to_char(0,'000'))
    Execution Plan
    Plan hash value: 424961364
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 553K| 55M| 1712 (1)| 00:00:21 |
    | 1 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 553K| 55M| 1712 (1)| 00:00:21 |
    |* 2 | INDEX RANGE SCAN | OMA_TEST | 99543 | | 605 (1)| 00:00:08 |
    Predicate Information (identified by operation id):
    2 - access(TO_CHAR("KNR",'00000000')||TO_CHAR("PROJNR",'00000000')||TO_CHAR("
    ACTNR",'00000000')||TO_CHAR("REGELNR",'000')>=TO_CHAR(100,'00000000')||TO_CHAR(3
    0,'00000000')||TO_CHAR(100000,'00000000')||TO_CHAR(0,'000'))

  • CDS-18010 Error:A Index and a index with the same name

    Hi
    I am facing strange error is some one expert there to help me to get rid of this error.
    CDS-18010 Error:A Index and a index with the same name 'LA_SP_FK_1' have been asked to be created.
    I am generating tables from Data model diagram & getting this error.
    Thanks,
    Vijay

    Your Right!!
    Designer does not like 2 of the same name.
    there are several bugs on the same name issue and CDS-18010
    Bug.3973155/3443005 (92) CDS-18010 IN CAPTURING A TYPE WITH CONSTRUCTOR FUNTIONS IN ITS BODY:
    Bug.2586582 (93) CDS-18010 A DOMAIN AND A DOMAIN WITH THE SAME NAME 'D1' BEEN ASKED TO CREATE:
    Bug.2561625 (15) CDS-18010 GENERATION OF TWO SYNONYMS WITH SAME NAME BUT DIFFERENT SCOPE:
    Bug.2072505 (93) CDS-18010 CAPTURING 2 TRIGGERS WITH SAME NAME ON ONE TABLE SHOULD BE A WARNING:
    Bug.1689800 (90) CDS-18010 PLSQL WITH THE SAME PROCEDURE NAME ALREADY EXISTS:
    Bug.1073311/1029997 (96) CDS-18010 ERROR ATTEMPTING TO CREATE 2 PROCEDURES WITH SAME NAME:
    Just to name a few.
    I would suggest you change the name.
    Michael

  • Issue While executing the Query for Pagination using ROWNUM with like

    Issue While executing the Query for Pagination using ROWNUM with like.
    Database is Oracle11G.
    Oracle Database Table contains 8-9 lakh records
    1) SQL equal (=)
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE A.REFERENCE = 'KMF22600920'
    Execution Time:- 0.00869245 seconds
    Returns 2 resultsets
    2) SQL like (one %)
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE A.REFERENCE = 'KMF22600920%'
    Execution Time:- 0.01094301 seconds
    Returns 2 resultsets
    3) SQL like (two%)
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE A.REFERENCE like '%KMF22600920%'
    Execution Time:- 6.43989658 seconds
    Returns 2 resultsets
    In Pagination, we are using Modified version of SQL Query 3) with ROWNUM as mentioned below :-
    4) SELECT * FROM (
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE REFERENCE like '%KMF22600920%' AND ROWNUM <= 20 ) WHERE RNUM > 0
    Execution Time:- Infinite
    ResultSets:- No as execution time is infinite
    a) Instead of like if we use = in the above query it is returning the 2 resultsets (execution time 0.02699282 seconds)
    b) Instead of two % in the above query, if use one example REFERENCE like 'KMF22600920%' it is returning the 2 resultsets (execution time 0.03313019 seconds)
    Issue:- When using two % in like in the above query i.e. REFERENCE like '%KMF22600920%' AND ROWNUM <= 20 ) , it is going to infinite.
    Could you please let us know what is the issue with two % used in like and rownum
    5) Modified version of Option1 query (move out the RNUM condition AND RNUM <= 20)
    SELECT * FROM (
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE REFERENCE like '%KMF22600920%' ) WHERE RNUM > 0 AND RNUM <= 20
    Execution Time:- 7.41368914 seconds
    Returns 2 resultsets
    Is the above query is best optimized query which should be used for the Pagination or still can improve on this ?

    This would be easier to diagnose if there was an explain plan posted for the 'good' and 'bad' queries. Generally speaking using '%' on both sides precludes the use of any indexes.

  • Linguistic index not being used

    I am using 10G database and am having an issue that my linguistic index is not being used during sorting.
    Any help will be appreciated.
    Table structure.
    create table TEST
    ID CHAR(256) not null,
    NAME VARCHAR2(100) not null,
    DESIGNATION VARCHAR2(200)
    alter table TEST add constraint ID primary key (ID)
    create index TEST_IDX on TEST (NLSSORT(NAME,'nls_sort=''GENERIC_M'''))
    Number of rows - 1 million
    Query being run.
    alter session set nls_sort='Generic_M';
    select * from test order by name;
    Explain plan
    PLAN_TABLE_OUTPUT
    | 0 | SELECT STATEMENT | | 1001K| 270M| | 70194 (1)| 00:14:0
    3 |
    | 1 | SORT ORDER BY | | 1001K| 270M| 579M| 70194 (1)| 00:14:0
    3 |
    | 2 | TABLE ACCESS FULL| TEST | 1001K| 270M| | 9163 (1)| 00:01:5
    0 |
    --------------------------------------------------------------------------------

    I don't think that's true, at least with the nls_sort function. I'm running into the same problem now, and I've traced with and without the use of the index, and it's definitely better with the index.
    Here it is, not using the index:
    SQL> select * from test where col2='sfs';
    no rows selected
    Execution Plan
    Plan hash value: 1357081020
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 366 | 2 (0)| 00:00:01 |
    |* 1 | TABLE ACCESS FULL| TEST | 1 | 366 | 2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    1 - filter(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('7366730
    0') )
    Note
    - dynamic sampling used for this statement
    Statistics
    87 recursive calls
    0 db block gets
    21 consistent gets
    0 physical reads
    0 redo size
    339 bytes sent via SQL*Net to client
    327 bytes received via SQL*Net from client
    1 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    0 rows processed
    And here it is WITH the index:
    SQL> select /*+ index_asc(test index1) */ * from test where col2='adsfas';
    no rows selected
    Execution Plan
    Plan hash value: 2960817241
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
    |
    | 0 | SELECT STATEMENT | | 1 | 366 | 2 (0)| 00:0
    0:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 366 | 2 (0)| 00:0
    0:01 |
    |* 2 | INDEX FULL SCAN | INDEX1 | 1 | | 1 (0)| 00:0
    0:01 |
    Predicate Information (identified by operation id):
    2 - access(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('6164736661730
    0') )
    filter(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('6164736661730
    0') )
    Note
    - dynamic sampling used for this statement
    Statistics
    11 recursive calls
    0 db block gets
    7 consistent gets
    0 physical reads
    0 redo size
    339 bytes sent via SQL*Net to client
    327 bytes received via SQL*Net from client
    1 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    0 rows processed
    Oddly enough, the optimizer chooses not to use the index on this example table I created.

  • Wrong result for query with like and %

    I have a strange problem with query with like and %.
    When I run this script:
    ALTER SESSION SET NLS_SORT = 'BINARY_CI';
    ALTER SESSION SET NLS_COMP = 'LINGUISTIC';
    -- SELECT * FROM NLS_SESSION_PARAMETERS;
    -- drop table test1;
    CREATE TABLE TEST1(K1 NVARCHAR2(80));
    INSERT INTO TEST1 VALUES ('gsdk');
    INSERT INTO TEST1 VALUES ('ąxyz');
    INSERT INTO TEST1 VALUES ('ŁFa');
    INSERT INTO TEST1 VALUES ('ła');
    INSERT INTO TEST1 VALUES ('Śab');
    INSERT INTO TEST1 VALUES ('Śrrrb');
    commit;
    select * from TEST1 where k1 like N'Ł%';
    I get this:
    K1
    ŁFa
    ła
    Śab <- WRONG
    Śrrrb <- WRONG
    4 rows selected
    When i change datatype to varchar2 this code work correct.
    Is this a bug or what ?
    The execution plan:
    PLAN_TABLE_OUTPUT
    SQL_ID d3d64aupz4bb5, child number 2
    select * from TEST1 where k1 like N'Ł%'
    Plan hash value: 4122059633
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | | | 2 (100)| |
    |* 1 | TABLE ACCESS FULL| TEST1 | 1 | 82 | 2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    1 - filter((NLSSORT("K1",'nls_sort=''BINARY_CI''')>=HEXTORAW('014200'
    ) AND NLSSORT("K1",'nls_sort=''BINARY_CI''')<HEXTORAW('01610100') ))
    Note
    - dynamic sampling used for this statement (level=2)

    DATABASE NLS CONFIGURATION:
    NLS_CHARACTERSET AL32UTF8
    NLS_NCHAR_CHARACTERSET     AL16UTF16
    NLS_COMP     BINARY
    NLS_SORT     BINARY
    Oracle version 11.2.0.2.0

  • DML operations performance on table indexed with CTXCAT

    Hi,
    I have a table with 2M records. The table is batch updated once a day, and the number of record movements (update/delete/insert) should be around 100K.
    The table is indexed with CTXCAT.
    If I create the index from scratch, it takes 5minutes.
    If I perform delete/insert/update operations involving 40K records, it takes a lot more (especially for delete and update operations, something like 30 minutes).
    In this particular case I can drop the index and recreate it from scratch every night. The problem is that the 2M records table is only the first step in adoption of Oracle Text. The next step will be a 40M records table, on which the initial index creation takes something like 2hours (so I can't rebuild it every night).
    Do you have any suggest?
    Thanks.
    -- table DDL
    CREATE TABLE TAHZVCON_TEXT
    CONSUMER_ID NUMBER(10) NOT NULL,
    COMPANY_NAME VARCHAR2(4000 CHAR),
    CITY VARCHAR2(30 BYTE),
    PROVINCE VARCHAR2(3 CHAR),
    POST_CODE VARCHAR2(10 BYTE)
    CREATE UNIQUE INDEX TAHZVCON_TEXT_PK ON TAHZVCON_TEXT (CONSUMER_ID);
    begin
    ctx_ddl.drop_preference('mylex');
    ctx_ddl.create_preference('mylex', 'BASIC_LEXER');
    ctx_ddl.set_attribute('mylex', 'printjoins', '.#');
    ctx_ddl.set_attribute('mylex', 'base_letter', 'YES');
    ctx_ddl.set_attribute('mylex', 'index_themes','NO');
    ctx_ddl.set_attribute('mylex', 'index_text','YES');
    ctx_ddl.set_attribute('mylex', 'prove_themes','NO');
    ctx_ddl.drop_preference('mywordlist');
    ctx_ddl.create_preference('mywordlist', 'BASIC_WORDLIST');
    ctx_ddl.set_attribute('mywordlist','stemmer','NULL');
    ctx_ddl.set_attribute('mywordlist','SUBSTRING_INDEX', 'NO');
    ctx_ddl.set_attribute('mywordlist','PREFIX_INDEX','NO');
    ctx_ddl.drop_index_set('tahzvcon_iset');
    ctx_ddl.create_index_set('tahzvcon_iset');
    ctx_ddl.add_index('tahzvcon_iset','city');
    ctx_ddl.add_index('tahzvcon_iset','province');
    ctx_ddl.add_index('tahzvcon_iset','post_code');
    end;
    CREATE INDEX TAHZVCON_TEXT_TI01 ON TAHZVCON_TEXT(COMPANY_NAME)
    INDEXTYPE IS CTXSYS.CTXCAT
    PARAMETERS ('lexer mylex wordlist mywordlist index set tahzvcon_iset')
    PARALLEL 8;
    Andrea

    Hi kevinUCB,
    I've decided to use CTXCAT indexes because I had to perform queries involving different columns (company name, city, region, etc.). So I thought CTXCAT was the right index for me.
    Now I've discovered that if I index an XML with CONTEXT, I can perform a search on single XML fields, so CONTEXT is suitable for my needs.
    Preliminary test on the 2M record table looks very good.
    Bye,
    Andrea

  • Case insensitive selects with 'like'

    I use a 10g database (10.2.0.2 same behaviour with 10.2.0.1). What we want is case insensitive selects with 'like' operator in the where clause. NLS_COMP is set to 'LINGUISTIC' and NLS_SORT is set to 'BINARY_CI.
    In a table we have two columns one of type 'varchar2' one of type 'nvarchar2'. The databases national character set is set to UTF8. Case insensitive sorting works with both columns. Select statements with '.... where varchar2col like '%r%' returns also values with upper case 'R' values (that is what I expect).
    The select statements with '.... where nvarchar2col like '%r%' however does not return the row with upper case 'R' values.
    I used SQL*Plus: Release 10.2.0.3.0 and other clients and the behaviour is the same so
    I think it is not client related.
    Is that a known issue or is there any other parameter to set for UTF8 nvarchar columns?
    Any hint is very much appreciated! Here are the nls settings in database, instance and session:
    DPARAMETER      DVALUE IVALUE SVALUE
    NLS_CHARACTERSET WE8ISO8859P1
    NLS_COMP      BINARY LINGUISTIC LINGUISTIC
    NLS_LANGUAGE      AMERICAN AMERICAN AMERICAN
    NLS_NCHAR_CHARACTERSET UTF8
    NLS_RDBMS_VERSION 10.2.0.1.0
    NLS_SORT BINARY BINARY_CI BINARY_CI
    NLS_TERRITORY      AMERICA AMERICA AMERICA

    OK. Found out what the problem is. It is obviously the client.
    While using the instant client and setting the parameters (NLS_SORT=BINARY_CI and NLS_COMP=LINGUISTIC) as environment variables does not work correctly, at least not for nvarchar2 fields. The nls_session_parameters show the correct values, but selects with 'like' operators in the where clause do not return case insensitive. Issuing the 'alter session' commands and again setting the nls parameters solves the problem.
    Using the full client installation also works, in case the parameters are set in the registry on windows systems. With the full client it it not necessary to issue the 'alter session' commands again.
    So obviously the problem is instant client and nvarchar2 field related. That's too bad....

  • Prevent automatic removal of the Spotlight index due to low disk space

    I am guessing that when disk space runs low, it automatically deletes the Spotlight index to make room for virtual memory. Then when space becomes available it reindexes. But I'm not sure about that.
    Since my MacBook Air SSD is only 128 GB, I often work with little free disk space and the re-indexing drives me crazy.
    I tried to disable Spotlight, remove its index and reindex. Also check filesystem and repair permissions. In diagnostic reports (~/Library/Logs/DiagnosticReports/) nothing about reindexing is mentioned.
    You can say that I should control the amount of free space but also should be another way. Disabling Spotlight isn't the option.
    Crosspost: http://apple.stackexchange.com/questions/37321/prevent-automatic-removal-of-the- spotlight-index-due-to-low-disk-space

    You can say that I should control the amount of free space .....
    Then I will
    See if you have Time Machine Local Backups taking up space, and turn it off with:
         sudo tmutil disablelocal
    Also consider turning off hibernate mode
    I am guessing that when disk space runs low, it automatically deletes the Spotlight index to make room for virtual memory. Then when space becomes available it reindexes. But I'm not sure about that.
    Not sure if that's the case, but low disk space can be causing issues.  What % of your HD is free?

  • APO DP Proportional factors with LIKE profile settings

    Can someone explain how Proportional factors get generated when we setup a new product with LIKE profile settings?  We are getting forecast generated at lower levels such as customer characteristic at levels we would not anticipate, and we don't see any proportional factors generated.
    Example: we have Existing product A and new product B.  We setup the LIKE profile for Product B to replace product A.  At the product level the forecast is generated correctly.  Currently product A has customers 1, 2, 3, 4 where customer 3 has 80% of the volume and customer 4 has 15% and customers 1 & 2 have the remaining volume.  When the forecast is generated for product B customer 4 is getting 60%, customer 3 50% and 1 & 2 the remaining volume.  There are no proportional factors generated for this new product.  When I try to create proportional factors for the new product it says there is no historical shipments to use which would be correct.  How do I get the dis aggregation of customers under product B to use the proportions that were used for product A?

    Hi Ganesh,
    Please refer following thread -
    APO DP proportional factor calculation
    Also you can refer to following link where its explained indetail -
    Generation of Proportional Factors - Master Data Setup - SAP Library
    Hope it helps.
    Regards,
    Alok

  • Error in "submit rmmmbest with ms_matnr-low = wa_matnr-low and return"?

    Hi
    Experts pls show me the solution for this error
    Error in "submit rmmmbest with ms_matnr-low = wa_matnr-low and return"?
    i have found error an during  extended syntax check for above statement . i.e3., ms_matnr-low is not a parameter or a select-option in report rmmmbest
    If anybody face this problem please tell me the solution.
    thanks in advance

    Hi Sitaram,
    The selection for material number is programmed with a select-option called MS_MATNR. Although you can see only MS_MATNR-low you should still fill an internal table with the same linetype as MS_MATNR and then use SUBMIT rmmbest with MS_MATNR = <your internal table>.
    e.g.
      DATA:
         zlt_matnr_range TYPE RANGE OF matnr,
         zls_matnr_line    LIKE LINE of zlt_matnr_range.
    zls_matnr_line-sigm  = 'I'.
    zls_matnr_line-option = 'EQ'.
    zls_matnr_line-low = wa_matnr-low.
    APPEND zls_matnr_line to zlt_matnr_range.
    SUBMIT rmmmbest WITH ms_matnr = zls_matnr_range.
    Regards,
    John.

  • Problem crating text index with PREFIX_INDEX option

    I am trying to create a text index with prefixes option for use in wildcard search scenarios.
    Here is the code I use:
    connect CTXSYS/*******
    BEGIN
    ctx_ddl.create_preference('wildcard_pref', 'BASIC_WORDLIST');
    ctx_ddl.set_attribute('wildcard_pref','PREFIX_INDEX','TRUE');
    ctx_ddl.set_attribute('wildcard_pref','PREFIX_MIN_LENGTH',3);
    ctx_ddl.set_attribute('wildcard_pref','PREFIX_MAX_LENGTH',8);
    ctx_ddl.set_attribute('wildcard_pref','SUBSTRING_INDEX','YES');
    END;
    And preference is created
    SELECT PRE_OWNER, PRE_NAME FROM CTXSYS.CTX_PREFERENCES;
    PRE_OWNER PRE_NAME
    CTXSYS WILDCARD_PREF
    CTXSYS DEFAULT_STORAGE
    CTXSYS DEFAULT_CLASSIFIER
    Now when I log as one of the database users and try to create the index,
    I got this:
    create index wildcard_idx on MY_Table(Name)
    indextype is ctxsys.context
    parameters ('WORDLIST wildcard_pref') ;
    create index wildcard_idx on MY_Table(Name)
    ERROR at line 1:
    ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
    ORA-20000: Oracle Text error:
    DRG-10700: preference does not exist: wildcard_pref
    ORA-06512: at "CTXSYS.DRUE", line 160
    ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 364
    What I am doing wrong ? Keep in mind that I was able to create a text index without the prefixes, but a lot of the searches will be based on patial word search.
    Eventualy I would also like to make those indexes be tansactional and work as a datastore (multiple column search)
    Thanks.
    Stefan

    Problem solved.
    Atrributes and preferences had to be created by the same user creating the index.
    Log as sysdba and
    GRANT EXECUTE ON CTX_DDL TO <user_that_creates_index>
    And it works.
    Message was edited by:
    Stef4o

Maybe you are looking for

  • Missing access rights to watch documents in BI Portal (Integrated Planning)

    Dear All, At the moment we are working on our first project with integrated planning. One of our requirements is to enter a long text to a planning position. Unfortunaltey we receive an error message while trying display the popup text box with the l

  • AppleTV compatible with Buffalo Linkstation Live?

    If you look it up, The LinkStation Live supports SMB and has a built in iTunes7 server. http://www.buffalotech.com/products/network-storage/linkstation/linkstation-live / Do you think I could plug this directly into the AppleTV via ethernet or would

  • Screen are not openning ?

    Hi All, I'm in entry stage of SD Module, Please help me, I & my computer stuck with a <b>system error</b>--Unable to lock Table/view V_TVAK. while going for tcode VOV8 as well as Path. --Unable to lock table/view V_TVKO while difining Sales Orgn. --U

  • Nokia Messaging causes N97 to reboot/switch off?

    Hi Guys, I've noticed there are some people who are running 12.0.24 firmware here who claim that their Nokia N97 'is working fine with no issues at all'. My question to you is are any of you people who have no reboot/turning off problems running Noki

  • Logging for CPO Workflows

    I would like to know if there is any logging mechanism in CPO to see what are the workflows that have run during a day and the errors that occurred during the execution of workflows. Thanks, Anish