Enocdedimage bitmap conversion.
Hello friends,
I get a server shape encoded image. I want to display in appropriate formats. If someone tell me how to convert encodedimage in bitmap image. No area of bitmap. Please tell me how to convert encoded bitmap image. Not with the bitmap field.
I use the following code.
InputStream in_i = conn.openInputStream();
final byte[] output=IOUtilities.streamToBytes(in_i);
in_i.close();
EncodedImage image= EncodedImage.createEncodedImage(output, 0,output.length);
Bfimage.setImage(image);// here bfimage is bitmapfield. i want bitmap.
above the code Bfimage is bitmapfield object I want to bitmap. Please tell me.
Thank you
Ajay
Image bitmap bitmap = image.getBitmap ();
You can use code above to obtain the coded Image Bitmap.
Tags: BlackBerry Developers
Similar Questions
-
CONVERSION of BITMAP OF ROWID and IFFS
Hello
A few days ago, I observed the strange behavior of a query that has counted the number of distinct attributes in a single partition of a large table. There is a local bitmap index on the specified column and I assumed that the request would not need to access the table information in the index. Indeed, the query has made an analysis of index full and no access table, but it took more time than I expected (more than 50 seconds in the given case). The sql, followed dbms_sqltune showed me, that most of the work has been associated with the BITMAP ROWID CONVERSION steps and a following GROUP BY of HASH. Then, I changed the query a little and got a much better performance without the BITMAP CONVERSION to ROWID and with a UNIQUE HASH - and operation with the same cost (and the same amount of LIOs). Here's a small suitcase of test 11.2.0.1 showing my remarks (on my Windows PC; "I've seen the effect in a Linux - 11.1.0.7 - data warehouse):
And here are the queries and dbms_sqltune.report_sql_monitor information:drop table t_partitioned; create table t_partitioned ( id number , startdate date , col1 number , padding varchar2(50) ) partition by range(startdate) ( partition t_partitioned_20120522 values less than (to_date('23.05.2012', 'dd.mm.yyyy')) , partition t_partitioned_20120523 values less than (to_date('24.05.2012', 'dd.mm.yyyy')) , partition t_partitioned_maxvalue values less than (maxvalue) ); insert into t_partitioned select rownum id , to_date('22.05.2012', 'dd.mm.yyyy') - 1 + trunc(rownum/500000) startdate , mod(rownum, 4) col1 , lpad('*', 50, '*') padding from dual connect by level <= 1000000; -- executed several times until the table contained 64M rows, i.e. 32M for each day partition. insert into t_partitioned select * from t_partitioned; commit; create bitmap index t_partitioned_col1_start_bix on t_partitioned(col1, startdate) local; exec dbms_stats.gather_table_stats(user, 't_partitioned')
The difference is in the little test 4,09 0.02 sec dry. It seems that slow execution must unpack the bitmaps for the separate number - but I do not understand why it is necessary, given that the number of distinct values is not the ROWID (and indeed the conversion seems to be preventable if I look at the quick plan). And to my surprise the simple query is slower.-- slow query select /*+ monitor test 1 */ count(distinct col1) from t_partitioned where startdate = to_date('22.05.2012', 'dd.mm.yyyy'); -- fast query select /*+ monitor test 2 */ count(*) from (select distinct col1 from t_partitioned where startdate = to_date('22.05.2012', 'dd.mm.yyyy')); -- Test 1 SQL Monitoring Report SQL Text ------------------------------ select /*+ monitor test 1 */ count(distinct col1) from t_partitioned where startdate = to_date('22.05.2012', 'dd.mm.yyyy') Global Information ------------------------------ Status : DONE (ALL ROWS) Instance ID : 1 Session : DBADMIN (67:178) SQL ID : 3mxmz941azrgx SQL Execution ID : 16777216 Execution Started : 05/22/2012 21:48:43 First Refresh Time : 05/22/2012 21:48:43 Last Refresh Time : 05/22/2012 21:48:47 Duration : 4s Module/Action : SQL*Plus/- Service : testdb Program : sqlplus.exe Fetch Calls : 1 Global Stats ================================================================ | Elapsed | Cpu | IO | Fetch | Buffer | Read | Read | | Time(s) | Time(s) | Waits(s) | Calls | Gets | Reqs | Bytes | ================================================================ | 4.09 | 3.54 | 0.55 | 1 | 5868 | 62 | 46MB | ================================================================ SQL Plan Monitoring Details (Plan Hash Value=3761143426) ================================================================================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | (%) | (# samples) | ================================================================================================================================================================================================== | 0 | SELECT STATEMENT | | | | 1 | +4 | 1 | 1 | | | | | | | 1 | SORT AGGREGATE | | 1 | | 1 | +4 | 1 | 1 | | | | | | | 2 | VIEW | VW_DAG_0 | 2602 | 5361 | 1 | +4 | 1 | 4 | | | | | | | 3 | HASH GROUP BY | | 2602 | 5361 | 4 | +1 | 1 | 4 | | | 840K | 50.00 | Cpu (2) | | 4 | PARTITION RANGE SINGLE | | 2602 | 5360 | 3 | +2 | 1 | 32M | | | | | | | 5 | BITMAP CONVERSION TO ROWIDS | | 2602 | 5360 | 3 | +2 | 1 | 32M | | | | 25.00 | Cpu (1) | | 6 | BITMAP INDEX FAST FULL SCAN | T_PARTITIONED_COL1_START_BIX | | | 3 | +2 | 1 | 5836 | 62 | 46MB | | 25.00 | db file scattered read (1) | ================================================================================================================================================================================================== -- Test 2 SQL Monitoring Report SQL Text ------------------------------ select /*+ monitor test 2 */ count(*) from (select distinct col1 from t_partitioned where startdate = to_date('22.05.2012', 'dd.mm.yyyy')) Global Information ------------------------------ Status : DONE (ALL ROWS) Instance ID : 1 Session : DBADMIN (67:178) SQL ID : 512z4htdq43cn SQL Execution ID : 16777216 Execution Started : 05/22/2012 21:48:49 First Refresh Time : 05/22/2012 21:48:49 Last Refresh Time : 05/22/2012 21:48:49 Duration : .019299s Module/Action : SQL*Plus/- Service : testdb Program : sqlplus.exe Fetch Calls : 1 Global Stats ================================================= | Elapsed | Cpu | Other | Fetch | Buffer | | Time(s) | Time(s) | Waits(s) | Calls | Gets | ================================================= | 0.02 | 0.02 | 0.00 | 1 | 5868 | ================================================= SQL Plan Monitoring Details (Plan Hash Value=4286208786) ======================================================================================================================================================================= | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (Max) | (%) | (# samples) | ======================================================================================================================================================================= | 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 1 | | | | | 1 | SORT AGGREGATE | | 1 | | 1 | +0 | 1 | 1 | | | | | 2 | VIEW | | 2602 | 5361 | 1 | +0 | 1 | 4 | | | | | 3 | HASH UNIQUE | | 2602 | 5361 | 1 | +0 | 1 | 4 | 840K | | | | 4 | PARTITION RANGE SINGLE | | 2602 | 5360 | 1 | +0 | 1 | 5836 | | | | | 5 | BITMAP INDEX FAST FULL SCAN | T_PARTITIONED_COL1_START_BIX | 2602 | 5360 | 1 | +0 | 1 | 5836 | | | | =======================================================================================================================================================================
I also did a trace of cbo (10053) but I don't see a good reason for the difference in behavior here:
So slow execution consider still more possible transformations - but obviously not the one fitting.-- fast execution ************************** Query transformations (QT) ************************** CBQT: Validity checks passed for 8kj3uttv3nt4j. CSE: Considering common sub-expression elimination in query block SEL$1 (#0) ... Final query after transformations:******* UNPARSED QUERY IS ******* SELECT COUNT(*) "COUNT(*)" FROM (SELECT DISTINCT "T_PARTITIONED"."COL1" "COL1" FROM "DBADMIN"."T_PARTITIONED" "T_PARTITIONED" WHERE "T_PARTITIONED"."STARTDATE"=TO_DATE(' 2012-05-22 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) "from$_subquery$_001" -- slow execution ************************** Query transformations (QT) ************************** JF: Checking validity of join factorization for query block SEL$1 (#0) JF: Bypassed: not a UNION or UNION-ALL query block. ST: not valid since star transformation parameter is FALSE TE: Checking validity of table expansion for query block SEL$1 (#0) TE: Bypassed: No relevant table found. CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries. CBQT: Validity checks failed for d0471pgnw27nc. CSE: Considering common sub-expression elimination in query block SEL$1 (#0) ... Final query after transformations:******* UNPARSED QUERY IS ******* SELECT COUNT("VW_DAG_0"."ITEM_1") "COUNT(DISTINCTCOL1)" FROM (SELECT "T_PARTITIONED"."COL1" "ITEM_1" FROM "DBADMIN"."T_PARTITIONED" "T_PARTITIONED" WHERE "T_PARTITIONED"."STARTDATE"=TO_DATE(' 2012-05-22 00:00:00', 'syyyy-mm-dd hh24:mi:ss') GROUP BY "T_PARTITIONED"."COL1") "VW_DAG_0"
The question is: I do not miss a semantic difference between the two queries and is there a good reason why the CBO does not have the transformation of the slow to the fast version?
Concerning
Martin Preissmpreiss wrote:
================================================================================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | (%) | (# samples) | ================================================================================================================================================================================================== | 0 | SELECT STATEMENT | | | | 1 | +4 | 1 | 1 | | | | | | | 1 | SORT AGGREGATE | | 1 | | 1 | +4 | 1 | 1 | | | | | | | 2 | VIEW | VW_DAG_0 | 2602 | 5361 | 1 | +4 | 1 | 4 | | | | | | | 3 | HASH GROUP BY | | 2602 | 5361 | 4 | +1 | 1 | 4 | | | 840K | 50.00 | Cpu (2) | | 4 | PARTITION RANGE SINGLE | | 2602 | 5360 | 3 | +2 | 1 | 32M | | | | | | | 5 | BITMAP CONVERSION TO ROWIDS | | 2602 | 5360 | 3 | +2 | 1 | 32M | | | | 25.00 | Cpu (1) | | 6 | BITMAP INDEX FAST FULL SCAN | T_PARTITIONED_COL1_START_BIX | | | 3 | +2 | 1 | 5836 | 62 | 46MB | | 25.00 | db file scattered read (1) | ==================================================================================================================================================================================================Martin,
I think it's just one of those things where the code for the optimizer is not uniform in all cases. I first met this anomaly with a query with a subquery IN a few years ago:
select dim.* from dim where id in ( select distinct status from area_sales ) ;If the breast to a view query online, but is not converted to a semi-join, so you see the same effect. This request is a little weird (it's a business model of the customer). Here is the list rows in a dimension table (with PK) which lies in the fact (with bitmap index) table.
--------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem | --------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 6 |00:00:00.01 | 29 | | | | |* 1 | HASH JOIN | | 1 | 6 | 6 |00:00:00.01 | 29 | 1594K| 1594K| 865K (0)| | 2 | VIEW | VW_NSO_1 | 1 | 6 | 6 |00:00:00.01 | 21 | | | | | 3 | HASH UNIQUE | | 1 | 6 | 6 |00:00:00.01 | 21 | 1595K| 1595K| 715K (0)| | 4 | BITMAP CONVERSION TO ROWIDS | | 1 | 100K| 100K|00:00:00.01 | 21 | | | | | 5 | BITMAP INDEX FAST FULL SCAN| AS_BI | 1 | | 30 |00:00:00.01 | 21 | | | | | 6 | TABLE ACCESS FULL | DIM | 1 | 6 | 6 |00:00:00.01 | 8 | | | | ---------------------------------------------------------------------------------------------------------------------------------The conversion does not occur if you rewrite the manual unnesting query:
select dim.* from ( select distinct status from area_sales ) sttv,I dim where dim.id = sttv.status ;The strange thing is the 10053 trace shows that this manual rewrite is (apparently) exactly the thing that is well optimized.
In the latest versions of Oracle, plans are lots of volumes and distribution - I saw half a dozen plans different for the same query through three different versions of Oracle.(In fact, you can see something similar, many queries with subquery costs where the subquery is involved in-the cost of the query automatically to the often seems to be slightly higher than the cost of the subquery manually to the when the manual and automatic plans are the same (otherwise)).
This really expected to have nothing to do with NULL values, moreover, because the bitmap indexes contain a string of NULL values.
Concerning
Jonathan Lewis -
When the CBO would not use bitmap indexes available?
I have a large data warehouse table in a star schema classic, with an index number of bitmap for the dimension tables. When you run queries that contain parameters for multiple indexes, the CBO will only use generally one or rarely two bitmap index.
It seems to me that if the indexes are valid, statistics, the values of the parameters are present, etc and the CBO uses a bitmap index in an AND condition, he would like to use all those she could.
there all the parameters that affect or bitmap how indexes him CBO will use? I'm looking for some advice on what to look for or research.
Database is 11.2.0.3 base with no patch.
Thanks in advance,
Sean
rp0428 - who has been deliberate because my question is not "how to solve this problem", that's exactly what I pointed out in my post. Just trying to see if there are all the controls to weight the decision-making community organizations in this area.
OK - then let me simply state it.
No - there are NO these parameters. But most of the posters are not really looking for a simple yes/no answer even if of many word of questions like that.
See my response as of March 18, 2012 19:21 in this thread: https://community.oracle.com/message/10219613?
Here I provide a simple table with SIX bitmap index, a query that uses predicates that combine values since the execution plan and the six columns indicating the different INDEX of BITMAP UNIQUE BITMAP, BITMAP or operations and BITMAP CONVERSION to ROWID.
I won't repeat everything here, but this example should show you that Oracle will limit itself the way you suggest.
-
Hello
I'm little surprised when creating index. I have a partition table with 10784102 files in them. one of its columns have distinct values 8558592 in them.
which is equal to 80% of the data in the table. This column cardinality is very high for btree indexes is good for this situation.
In addition, there no null values in the column as well. However, when I create a btree index
and make a simple index select does not scan. While when I create bitmap on this column indexes it scan index. Here is my test scenario
The two queries of different time taken bitmap, return in 8 seconds while the index btree take 2mints.Btree index explain plan for select SESS_SESSESSIONID from REBE01S2_DG0 SELECT * FROM table(dbms_xplan.display); explain plan succeeded. PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Plan hash value: 854853906 ---------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib | ---------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10M| 287M| 103K (1)| 00:24:07 | | | | | | | 1 | PX COORDINATOR | | | | | | | | | | | | 2 | PX SEND QC (RANDOM)| :TQ10000 | 10M| 287M| 103K (1)| 00:24:07 | | | Q1,00 | P->S | QC (RAND) | | 3 | PX BLOCK ITERATOR | | 10M| 287M| 103K (1)| 00:24:07 | 1 | 15 | Q1,00 | PCWC | | | 4 | TABLE ACCESS FULL| REBE01S2_DG0 | 10M| 287M| 103K (1)| 00:24:07 | 1 | 15 | Q1,00 | PCWP | | ---------------------------------------------------------------------------------------------------------------------------------- 11 rows selected *drop btree and create bitmap* PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Plan hash value: 1533847669 ----------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib | ----------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10M| 287M| 7170 (1)| 00:01:41 | | | | | | | 1 | PX COORDINATOR | | | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10000 | 10M| 287M| 7170 (1)| 00:01:41 | | | Q1,00 | P->S | QC (RAND) | | 3 | PX BLOCK ITERATOR | | 10M| 287M| 7170 (1)| 00:01:41 | 1 | 15 | Q1,00 | PCWC | | | 4 | BITMAP CONVERSION TO ROWIDS | | 10M| 287M| 7170 (1)| 00:01:41 | | | Q1,00 | PCWP | | | 5 | BITMAP INDEX FAST FULL SCAN| MINDX_REBE01S2_DG0_0 | | | | | 1 | 15 | Q1,00 | PCWP | | ----------------------------------------------------------------------------------------------------------------------------------------------------- 12 rows selected
Oracle Database 11 g Enterprise Edition Release 11.2.0.3.0 - 64 bit Production
AMT for 64-bit Windows: Version 11.2.0.3.0 - Production
Table and index both partition local. Rangeuser10858330 wrote:
Hi Jonathan when I use strange terms of suspicion is explain. Pleas take a lookThe first plan that you have demonstrated is exactly as planned during the sess_sesssessionid has not been declared as NOT NULL. However, I notice that you have modified the original request.
select /*+ index_FFS(REBE01S2_DG0(SESS_SESSESSIONID)) */ distinct SESS_SESSESSIONID from REBE01S2_DG0When I remove indication FFS it use another column index
MINDX_REBE01S2_DG0_3 please specify thisBut in the previous post in response to Hemant, there no - this suggests that you are mixing up of your experiences.
And you certainly don't expect to guess what is happening with the other indexes when you don't have it yet we gave the definition of the index.Because the column has not been declared NOT NULL, there wasn't any point in trying to the indicator. Instead you might (for the purpose of investigating a point) run your query with the predicate "sess_sessessionid is not null.
Concerning
Jonathan Lewis -
Hi all
Is it possible to use the Index BITMAP for a NOT NULL condition?
>
CREATE a BITMAP of INDEX x_ix FOR tab (x);
SELECT *.
TAB
WHERE x IS NOT NULL
>
Thank you!user3646231 wrote:
You say that :) to hopeHere it is:
Your test is a good effort - but it needs a little more.
Your question is "is it possible...". «, not "If Oracle always...» »
Your demonstration showed an example where the choice of plan Oracle has surprised you (and me). Now, you need run the query with index indicator (because if the indexed access path is legal, must be taken an indexed correctly suggested path).
I just ran a similar test (1 line of 100,000), with the following results:
SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------ SQL_ID 52q6gxkscvg9v, child number 0 ------------------------------------- select /*+ index(t1(n1)) */ * from t1 where n1 is not null Plan hash value: 2828957992 ---------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | ---------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 1859 | | 1 | TABLE ACCESS BY INDEX ROWID | T1 | 1 | 118 | 1859 | | 2 | BITMAP CONVERSION TO ROWIDS| | | | | |* 3 | BITMAP INDEX FULL SCAN | T1_N1 | | | | ---------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter("N1" IS NOT NULL)You will notice that the cost of the query is unreasonable - and without the suspicion my test showed Oracle taking the full analysis at a much lower cost.
If your test has actually demonstrated a bug in the costing, explaining why Oracle does not automatically take a path that seems reasonable.The above output comes from 11.2.0.3, but I had the same thing with 11.1.0.7
Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
Author: core Oracle -
Hello
Why in the example below Oracle does not use the default bitmap index?
Oracle 11g R1
Windows 2003 SP2SQL> desc names3 Name Null? Type ----------------------------------------- -------- ---------------------------- ID NUMBER NAME NOT NULL VARCHAR2(50) HDATE DATE SAL NUMBER REGION VARCHAR2(1) SQL> create bitmap index names3i1 on names3(region ) ; Index created. SQL> exec dbms_stats.gather_table_stats('HRS','NAMES3') ; PL/SQL procedure successfully completed. SQL> exec dbms_stats.gather_index_stats('HRS','NAMES3I1') ; PL/SQL procedure successfully completed. SQL> select count(*) from names3 SQL> / COUNT(*) ---------- 200056 SQL> select * 2 from names3 n 3 where region = 'S' ; ---------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 400 | 2 (0)| 00:00:01 | |* 1 | TABLE ACCESS FULL| NAMES3 | 10 | 400 | 2 (0)| 00:00:01 | ---------------------------------------------------------------------------- SQL> ed Wrote file afiedt.buf 1 select /*+ index(n names3i1) */ 2 * 3 from names3 n 4* where region = 'S' SQL> / ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 400 | 2 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID | NAMES3 | 10 | 400 | 2 (0)| 00:00:01 | | 2 | BITMAP CONVERSION TO ROWIDS| | | | | | |* 3 | BITMAP INDEX SINGLE VALUE | NAMES3I1 | | | | | -----------------------------------------------------------------------------------------How many lines have in fact the region = s '?
What is the size of the table - in BLOCKS?
When you do a "select *", you ask Oracle to retrieve all columns. Therefore, Oracle knows that he will have to go to the table 10 times. It's 10 reading separate calls. Now, if the total size of the table is not great (and the size of your line is small), Oracle may choose to make a FullTableScan if she has less need (even if mulitblock) read calls.
If you ran a query as
select count(*) from name3 where region='S';You can compare the difference.
Hemant K Collette
http://hemantoracledba.blogspot.com -
use OPT_ESTIMATE or CARDINALITY tip for correct estimation of nested loops
I'm using Oracle 11.2.0.3. Below the execution below plan, how can I use tip OPT_ESTIMATE or CARDINALITY to teach optimization E-lines for ID 9 (Nested Loop) 30553 instead of 6.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | | | 4604 (100)| | 30553 |00:00:02.56 | 208K| | | | | 1 | SORT ORDER BY | | 1 | 6 | 7044 | 4604 (1)| 00:01:05 | 30553 |00:00:02.56 | 208K| 41M| 2086K| 36M (0)| |* 2 | HASH JOIN OUTER | | 1 | 6 | 7044 | 4603 (1)| 00:01:05 | 30553 |00:00:02.10 | 208K| 38M| 3120K| 39M (0)| |* 3 | HASH JOIN OUTER | | 1 | 6 | 6870 | 4599 (1)| 00:01:05 | 30553 |00:00:01.97 | 208K| 38M| 3120K| 39M (0)| |* 4 | HASH JOIN OUTER | | 1 | 6 | 6744 | 4591 (1)| 00:01:05 | 30553 |00:00:01.85 | 208K| 37M| 3121K| 39M (0)| |* 5 | HASH JOIN OUTER | | 1 | 6 | 6570 | 4584 (1)| 00:01:05 | 30553 |00:00:01.74 | 208K| 37M| 3121K| 38M (0)| |* 6 | HASH JOIN OUTER | | 1 | 6 | 6414 | 4576 (1)| 00:01:05 | 30553 |00:00:01.60 | 208K| 37M| 3121K| 38M (0)| | 7 | NESTED LOOPS | | 1 | | | | | 30553 |00:00:01.44 | 208K| | | | | 8 | NESTED LOOPS | | 1 | 6 | 6318 | 4572 (1)| 00:01:05 | 30553 |00:00:01.31 | 182K| | | | | 9 | NESTED LOOPS | | 1 | 6 | 1830 | 4568 (1)| 00:01:04 | 30553 |00:00:01.11 | 124K| | | | |* 10 | HASH JOIN | | 1 | 2069 | 270K| 2499 (1)| 00:00:35 | 30646 |00:00:00.46 | 23738 | 6539K| 2033K| 7965K (0)| |* 11 | TABLE ACCESS BY INDEX ROWID | DSCLR | 1 | 5079 | 158K| 533 (1)| 00:00:08 | 91395 |00:00:00.28 | 6460 | | | | | 12 | BITMAP CONVERSION TO ROWIDS | | 1 | | | | | 197K|00:00:00.16 | 615 | | | | | 13 | BITMAP AND | | 1 | | | | | 4 |00:00:00.14 | 615 | | | | | 14 | BITMAP OR | | 1 | | | | | 4 |00:00:00.07 | 276 | | | | | 15 | BITMAP CONVERSION FROM ROWIDS| | 1 | | | | | 2 |00:00:00.02 | 69 | | | | |* 16 | INDEX RANGE SCAN | XIF913DSCLR | 1 | 274K| | 14 (0)| 00:00:01 | 68407 |00:00:00.01 | 69 | | | | | 17 | BITMAP CONVERSION FROM ROWIDS| | 1 | | | | | 4 |00:00:00.05 | 207 | | | | |* 18 | INDEX RANGE SCAN | XIF913DSCLR | 1 | 274K| | 42 (0)| 00:00:01 | 209K|00:00:00.03 | 207 | | | | | 19 | BITMAP CONVERSION FROM ROWIDS | | 1 | | | | | 5 |00:00:00.06 | 339 | | | | |* 20 | INDEX RANGE SCAN | XIF910DSCLR | 1 | 274K| | 67 (0)| 00:00:01 | 239K|00:00:00.04 | 339 | | | | | 21 | NESTED LOOPS | | 1 | | | | | 21749 |00:00:00.10 | 17278 | | | | | 22 | NESTED LOOPS | | 1 | 3404 | 339K| 1965 (1)| 00:00:28 | 22772 |00:00:00.03 | 1246 | | | | | 23 | TABLE ACCESS FULL | TMP_RPT_BD_STATE_DATA_DWNLD | 1 | 3255 | 257K| 11 (0)| 00:00:01 | 3255 |00:00:00.01 | 27 | | | | |* 24 | INDEX RANGE SCAN | XIE2OCRN | 3255 | 7 | | 1 (0)| 00:00:01 | 22772 |00:00:00.03 | 1219 | | | | |* 25 | TABLE ACCESS BY INDEX ROWID | OCRN | 22772 | 1 | 21 | 1 (0)| 00:00:01 | 21749 |00:00:00.06 | 16032 | | | | |* 26 | VIEW PUSHED PREDICATE | | 30646 | 1 | 171 | 1 (0)| 00:00:01 | 30553 |00:00:00.63 | 101K| | | | | 27 | WINDOW BUFFER | | 30646 | 1 | 21 | 1 (0)| 00:00:01 | 46946 |00:00:00.59 | 101K| 2048 | 2048 | 2048 (0)| |* 28 | TABLE ACCESS BY INDEX ROWID | DSCLR_FLNG | 30646 | 1 | 21 | 1 (0)| 00:00:01 | 46946 |00:00:00.32 | 101K| | | | |* 29 | INDEX RANGE SCAN | XIE1DSCLR_FLNG | 30646 | 2 | | 1 (0)| 00:00:01 | 46946 |00:00:00.21 | 59862 | | | | |* 30 | INDEX RANGE SCAN | XPKH760_RGLTY_ACTN_DSCLR | 30553 | 1 | | 1 (0)| 00:00:01 | 30553 |00:00:00.18 | 57541 | | | | | 31 | TABLE ACCESS BY INDEX ROWID | H760_RGLTY_ACTN_DSCLR | 30553 | 1 | 748 | 1 (0)| 00:00:01 | 30553 |00:00:00.11 | 26218 | | | | | 32 | TABLE ACCESS FULL | DSCLR_ST_TYPE_TBL | 1 | 4 | 64 | 4 (0)| 00:00:01 | 4 |00:00:00.01 | 5 | | | | | 33 | TABLE ACCESS FULL | RGLTY_RSLTN_TYPE_TBL | 1 | 12 | 312 | 7 (0)| 00:00:01 | 12 |00:00:00.01 | 10 | | | | | 34 | TABLE ACCESS FULL | INTTR_TYPE_TBL | 1 | 14 | 406 | 7 (0)| 00:00:01 | 14 |00:00:00.01 | 10 | | | | | 35 | TABLE ACCESS FULL | SNCTN_TYPE_TBL | 1 | 15 | 315 | 7 (0)| 00:00:01 | 15 |00:00:00.01 | 10 | | | | | 36 | TABLE ACCESS FULL | PRDCT_TYPE_TBL | 1 | 25 | 725 | 4 (0)| 00:00:01 | 25 |00:00:00.01 | 5 | | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Query Block Name / Object Alias (identified by operation id): ------------------------------------------------------------- 1 - SEL$A8B7A3F4 11 - SEL$A8B7A3F4 / D@SEL$13 23 - SEL$A8B7A3F4 / OH@SEL$1 24 - SEL$A8B7A3F4 / O@SEL$13 25 - SEL$A8B7A3F4 / O@SEL$13 26 - SEL$13512960 / DF@SEL$13 27 - SEL$13512960 28 - SEL$13512960 / DF1@SEL$14 29 - SEL$13512960 / DF1@SEL$14 30 - SEL$A8B7A3F4 / H7@SEL$2 31 - SEL$A8B7A3F4 / H7@SEL$2 32 - SEL$A8B7A3F4 / DS@SEL$9 33 - SEL$A8B7A3F4 / RST@SEL$11 34 - SEL$A8B7A3F4 / ITT@SEL$3 35 - SEL$A8B7A3F4 / ST@SEL$5 36 - SEL$A8B7A3F4 / PT@SEL$7 Outline Data ------------- /*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('11.2.0.3') DB_VERSION('11.2.0.3') OPT_PARAM('optimizer_index_cost_adj' 20) ALL_ROWS OUTLINE_LEAF(@"SEL$13512960") PUSH_PRED(@"SEL$A8B7A3F4" "DF"@"SEL$13" 11) OUTLINE_LEAF(@"SEL$A8B7A3F4") ELIMINATE_JOIN(@"SEL$2D47CDEA" "DTT"@"SEL$13") OUTLINE(@"SEL$14") OUTLINE(@"SEL$A8B7A3F4") ELIMINATE_JOIN(@"SEL$2D47CDEA" "DTT"@"SEL$13") OUTLINE(@"SEL$2D47CDEA") MERGE(@"SEL$3FAACB6D") OUTLINE(@"SEL$15") OUTLINE(@"SEL$3FAACB6D") MERGE(@"SEL$11") MERGE(@"SEL$A1A6E401") OUTLINE(@"SEL$12") OUTLINE(@"SEL$11") OUTLINE(@"SEL$A1A6E401") MERGE(@"SEL$9") MERGE(@"SEL$BFB1842A") OUTLINE(@"SEL$10") OUTLINE(@"SEL$9") OUTLINE(@"SEL$BFB1842A") MERGE(@"SEL$7") MERGE(@"SEL$EEDE2B8C") OUTLINE(@"SEL$8") OUTLINE(@"SEL$7") OUTLINE(@"SEL$EEDE2B8C") MERGE(@"SEL$5") MERGE(@"SEL$A6B38458") OUTLINE(@"SEL$6") OUTLINE(@"SEL$5") OUTLINE(@"SEL$A6B38458") MERGE(@"SEL$171BE69E") MERGE(@"SEL$3") OUTLINE(@"SEL$4") OUTLINE(@"SEL$171BE69E") MERGE(@"SEL$AF02BF1E") OUTLINE(@"SEL$3") OUTLINE(@"SEL$2") OUTLINE(@"SEL$AF02BF1E") MERGE(@"SEL$13") OUTLINE(@"SEL$1") OUTLINE(@"SEL$13") FULL(@"SEL$A8B7A3F4" "OH"@"SEL$1") INDEX(@"SEL$A8B7A3F4" "O"@"SEL$13" ("OCRN"."ORG_PK" "OCRN"."DSCLR_DSCLB_FL" "OCRN"."DSCLR_RPTBL_FL")) BITMAP_TREE(@"SEL$A8B7A3F4" "D"@"SEL$13" AND(OR(1 1 ("DSCLR"."FORM_TYPE_CD") 2 ("DSCLR"."FORM_TYPE_CD")) ("DSCLR"."DSCLR_TYPE_CD"))) NO_ACCESS(@"SEL$A8B7A3F4" "DF"@"SEL$13") INDEX(@"SEL$A8B7A3F4" "H7"@"SEL$2" ("H760_RGLTY_ACTN_DSCLR"."FLNG_PK" "H760_RGLTY_ACTN_DSCLR"."DSCLR_PK" "H760_RGLTY_ACTN_DSCLR"."REC_SEQ_NB")) FULL(@"SEL$A8B7A3F4" "DS"@"SEL$9") FULL(@"SEL$A8B7A3F4" "RST"@"SEL$11") FULL(@"SEL$A8B7A3F4" "ITT"@"SEL$3") FULL(@"SEL$A8B7A3F4" "ST"@"SEL$5") FULL(@"SEL$A8B7A3F4" "PT"@"SEL$7") LEADING(@"SEL$A8B7A3F4" "OH"@"SEL$1" "O"@"SEL$13" "D"@"SEL$13" "DF"@"SEL$13" "H7"@"SEL$2" "DS"@"SEL$9" "RST"@"SEL$11" "ITT"@"SEL$3" "ST"@"SEL$5" "PT"@"SEL$7") USE_NL(@"SEL$A8B7A3F4" "O"@"SEL$13") NLJ_BATCHING(@"SEL$A8B7A3F4" "O"@"SEL$13") USE_HASH(@"SEL$A8B7A3F4" "D"@"SEL$13") USE_NL(@"SEL$A8B7A3F4" "DF"@"SEL$13") USE_NL(@"SEL$A8B7A3F4" "H7"@"SEL$2") NLJ_BATCHING(@"SEL$A8B7A3F4" "H7"@"SEL$2") USE_HASH(@"SEL$A8B7A3F4" "DS"@"SEL$9") USE_HASH(@"SEL$A8B7A3F4" "RST"@"SEL$11") USE_HASH(@"SEL$A8B7A3F4" "ITT"@"SEL$3") USE_HASH(@"SEL$A8B7A3F4" "ST"@"SEL$5") USE_HASH(@"SEL$A8B7A3F4" "PT"@"SEL$7") SWAP_JOIN_INPUTS(@"SEL$A8B7A3F4" "D"@"SEL$13") INDEX_RS_ASC(@"SEL$13512960" "DF1"@"SEL$14" ("DSCLR_FLNG"."DSCLR_PK" "DSCLR_FLNG"."BLLBL_FL")) END_OUTLINE_DATA */This plan gives you an idea of why your initial synchronization has been long - most of your readings are one-piece readings and you have read 53 724 blocks. If you estimate 1 centisecond by read (which could be on a reasonable charge system) then it is 537 seconds. to 5 milliseconds per read, it's still 268 seconds or 4 minutes and 30 seconds.
A quick break down of some (the worst case) potential time - only you can say whether or not some of these readings will be always/often/never being cached in the file or at the SAN level.
Line 11 - physical reads 6 400 done - it's a tree bitmap then the readings are in the order of physical table with no. rereads. Call 5ms by read-online 32 seconds. L
| * 11 | TABLE ACCESS BY INDEX ROWID | DSCLR | 1. 5079. 158K | 533 (1) | 00:00:08 | 91395 | 00:00:01.27 | 6460. 6400 | | | |
The hash join takes us from 6 400 to 11 788 because it joins, lines 21 to 25 (nested loop) in which most of the work is the random access table with some automatic caching: 26 seconds. Do a search here rather than indexed 22 000 access? Which would be faster, which would charge less.
| * 25. TABLE ACCESS BY INDEX ROWID | OCRN | 22050. 1. 21. 1 (0) | 00:00:01 | 21059 | 00:01:04.74 | 15634 | 5280. | | |
Three nested loops that introduce more readings:
11788 9-> 26386:14 600 of the predicate view pushed which some lies but a very large index and a table of random access 73 seconds
8 26386-> 33783:7 400 index line 30 - big clue about 37 seconds Access hides
33783 7-> 53691:19 900 31 table access - large table line, not much caching, 100 seconds.
In each case, you can ask if an analysis would take less time than all of these random reads.
NOTE - all I'm pointing our here where you potentially use a lot of time so that you can ask whether or not you should do little of the query in this way, or if there is an alternative, or if the work you're doing is absolutely necessary. If you want to optimize the query you should consider the intent of the query and think your way through a reasonable join order to see if you can imagine an effective way to get the same data. I have written a few articles and presentation on an approach that begins by drawing - here is a link to an article I wrote for a group of SQL Server: https://www.simple-talk.com/sql/performance/designing-efficient-sql-a-visual-approach/
and a video I did with Kyle Hailey, while he was working for Embarcadero:Tune in for the ultimate SQL Tune-off | Landing pages
Concerning
Jonathan Lewis
-
Explain the interpretation of the Plan
Hi friends!
I ve an anomaly in time of response of two databases that are equal between the two when I run the same query.
On the first DB, when I run the query it takes 20 seconds, but on the second DB, the same query at 02:40 minutes.
This Don t of sense to me, because the first DB contains a lot of data as second DB...
I ve got the plan to explain both, but I Don t know how to interpret.
It's the first DB EP, which is the fastest to execute the query (20 "):
********************************************************************************************************************************************************************************************
SELECT STATEMENT CHOOSECost: 4 K bytes: 934 K cardinality: 4 K
ORDER of 17 SORTING BY cost: 4 K bytes: 934 K cardinality: 4 K
FILTER 16
13 LOOPS IMBRIQUEES SEMI cost: 4 K bytes: 934 K cardinality: 4 K
TABLE 11 ACCESS BY INDEX ROWID IMO. IDDPAR cost: 4 K bytes: 892 K cardinality: 4 K
BITMAP 10 ROWID CONVERSION
9 BITMAP AND
5 BITMAP OR
2 BITMAP CONVERSION TO ROWID
1 INDEX RANGE SCAN NON-UNIQUE IMO. IDDPARX10 Cost: 306
CONVERSION OF BITMAP ROWID 4
3 INDEX RANGE SCAN NON-UNIQUE IMO. IDDPARX10 Cost: 3
CONVERSION OF BITMAP TO 8 ROWID
7 SORT ORDER BY
6 INDEX RANGE SCAN NON-UNIQUE IMO. IDDPARX3 Cost: 455
12 INDEX UNIQUE SCAN UNIQUE IMO. PK_IDDPACX1 bytes: 670 K cardinality: 62 K
TABLE 15 ACCESS BY INDEX ROWID IMO. IDDPARE cost: 1 bytes: cardinality 1: 16
14 INDEX UNIQUE SCAN UNIQUE IMO. Cardinality of PK_IDDPAREX1: 1
********************************************************************************************************************************************************************************************
And it's the second DB, for the same query of course EP (2'40 "):
**********************************************************************************************************************************************************
SELECT STATEMENT CHOOSECost: 6 K bytes: 886 K cardinality: 4 K
7 FILTER
4 LOOPS IMBRIQUEES SEMI cost: 6 K bytes: 886 K cardinality: 4 K
TABLE 2 ACCESS BY INDEX ROWID IMO. IDDPAR cost: 6 K bytes: 850 K cardinality: 4 K
1 INDEX RANGE SCAN NON-UNIQUE IMO. IDDPARX5 cost: 298 cardinality: 11 K
UNIQUE 3 INDEX SCAN UNIQUE IMO. PK_IDDPACX1 bytes: 417KO cardinality: 43 K
TABLE 6 ACCESS BY INDEX ROWID IMO. IDDPARE cost: 1 bytes: cardinality 1: 16
5 INDEX UNIQUE SCAN UNIQUE IMO. Cardinality of PK_IDDPAREX1: 1
**********************************************************************************************************************************************************
As you can see, second EP is as simple, but its effectiveness is much poorer.
I m intends to interpret my experience with Plans to explain, but it is virtually zero. The most obvious difference I found is the BITMAP CONVERSION OF LINES and CONVERSION of bitmap to LINES Kael'thas appear in the first EP.
I searched ´ve documentation CONVERSION BITMAP and I ve include, more or less. But I Don t know what measures to take to optimizer are Oracle do the same conversion on the second EP.
I Don t pretend that someone to teach me everything on explains Plans for interpretation, I m aware of the track of this.
But would like advice on how I can solve this problem. Any suggestion will be welcome.
Thanks in advance
AlexTutor wrote:
All databases are Enterprise Edition.
And I ve already tried with advice like that of...
Okay - so now that you have shown us the request, can you show us EXACTLY what the real "index_combine" referring to the fact that you used looked like and tell us if the execution plan has changed at all with this suspicion.
Note: Oracle does not ignore the advice, so if your data structures are the same, and you have the right to hint, Oracle would HAVE to give you the plan you want. The only reason why he could not is if the presence of the indication caused Oracle to examine an alternative implementation plan which was (a) cheaper than suggested and (b) a plan which the index was illegal.
Concerning
Jonathan Lewis
-
As separations output channels
Hello
I want to the output of the channels of Photoshop CC2014 files pdf separated. I make time to another screenshot for t-shirts.
I tried to export as files DCS2 and placing in InDesign and Illustrator. The test of Illustrator was best and works very well with ordinary flat colors and to some extend with screens as well.
My question is about the display of screens (as visible crispy points in the pdf)
For example, I made a drawing where one of the colors has a coarse 20 l/boost effect to it, and I tried this approach:
-Channels in photoshop set as spotcolours (screens made through bitmap conversion channel holding the halftone graphics, so it is crisp and black/white)
-Recording to the DCS 2.0 format
-import the DCS 2.0 file in Illustrator CC2014
-printing of one postscriptfile as a separation and conversion in Adobe Acrobat Distiller.
It results in sort of a blurry version of my screens. Where can I go wrong?
Does anyone know how this can be done?
Thank you for your time :·)
++ Michael
It seems that some anti-aliasing. What do you see if you open the DCS file in Photoshop? I just tried, and the points I see are crunchy. If it's the same thing for you, then you know that the problem is in Illy or the Distiller.
-
Hello
(Database version: 11 GR 2)
I'm running a sql query using sqlplus with the following options:
set timing on
Set autotrace traces
Why am I getting the following time:
Elapsed time: 00:00:00.00
but explain plan I see longer time?
I don't really understand why the BITMAP CONVERSION is in use (I have just the index b-tree).| Id | Operation | Name | Rows | Bytes |TempSpc | Cost (%CPU)| Time | Pstart| Pstop | -------------------------------------------------------------------------------- ----------------------------------------- | 0 | SELECT STATEMENT | | 216K| 3385K| | 9346 (1)| 00:06:15 | | | | 1 | PARTITION RANGE OR | | 216K| 3385K| | 9346 (1)| 00:06:15 |KEY(OR)|KEY(OR)| |* 2 | TABLE ACCESS BY LOCAL INDEX ROWID| LOG | 216K| 3385K|| 9346 (1)| 00:06:15 |KEY(OR)|KEY(OR)| | 3 | BITMAP CONVERSION TO ROWIDS | | | | | | | | | | 4 | BITMAP OR | | | | | | | | | | 5 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | | 6 | SORT ORDER BY | | | | 7912K| | | | | |* 7 | INDEX RANGE SCAN | LOG_PK | | | 818 (0)| 00:00:33 |KEY(OR)|KEY(OR)| | 8 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | | | 9 | SORT ORDER BY | | | | 7848K | | | | |* 10 | INDEX RANGE SCAN | LOG_PK | | | | 812 (1)| 00:00:33 |KEY(OR)|KEY(OR)| -------------------------------------------------------------------------------- -----------------------------------------
Thank you
Published by: user8897201 on 16 January 2013 02:39Hello
the server is able to convert the b * tree index in bitmaps in memory and combine the result works effectively or BITMAP. You will find a small example on the site of Julian Dyke: http://www.juliandyke.com/Optimisation/Operations/BitmapConversionFromRowids.html (you see there that the conversion is not a novelty).
Given your elapsed time, the CBO did a good job in this case.
Concerning
Martin
-
Operation in the execution plan list
Oracle 11.2.0.1
Windows xp
Kindly give me documentation link from where I can get the complete list of all the different operations that appears in a plan of execution with their details and priority / sequence of operations.
Thank you.Hello
I think it would have been much more useful for it if you read the link I provided and doing the job yourself, but anyway:
(1) BITMAP INDEX C1_IND SINGLE VALUE
(2) BITMAP INDEX C2_IND SINGLE VALUE
(3 take a NEGATIVE 1 sign) and 2).
(4) SINGLE C2_IND OF BITMAP INDEX VALUE
((5) BITMAP UNDER 4) and 3)
(6) BITMAP INDEX C3_IND RANGE SCAN, followed by the MERGER of BITMAP
((7) BITMAP or 5) and 6)
((8) BITMAP CONVERSION TO ROWID of 7)
(TABLE 9) ACCESS T BY INDEX ROWID, using rowid got in 8)
(10) the results returned to the userBest regards
Nikolai -
SELECT on a table in the INSERT statement uses the INDEX
Hello world
I have a strange problem with EA Oracle 10 g (64-bit) running on a Linux system. The situation is, I developed a Java program to migrate one client system to another. One of the steps in the migration fills a new table with the data from the old system. Given that the data on the old system structure is fundamentally different from that new, I have to check each time I read a line from the old system, if I have already created an entity on the new table, and if so, update certain attributes. The WHERE clause of this audit uses a key of the company indexed on the new table. The problem is now, that Oracle does not use the index on the key attribute of the company, but it makes table scans complete to select the line. As you can imagine, the lines first thousand or so go fast, but the amount increases, the program becomes slower and slower.
If I do a "scan" when executing the migration program, Oracle change the execution plan and use the index on the attribute key and everything works fast and smooth. However, if I do the analysis on the empty table first, nothing changes (which I understand it perfectly, since there is nothing to analyze, at this point). By integrating a hint of 'INDEX' (table) in the statement SELECT does not change the full implementation plan (also table scans).
Is it possible to change this behavior, in order to SELECT it uses the index of key business from the beginning?
Greetings from Cologne,
Thorsten.
Published by: thkitz on 13.03.2012 18:27thkitz wrote:
SELECT STATEMENT ALL_ROWSCost: 2 Bytes: 76 Cardinality: 2 7 TABLE ACCESS BY INDEX ROWID TABLE AIDATINT.PRVVSSCHADENKORRESPONDENZ Cost: 2 Bytes: 76 Cardinality: 2 6 BITMAP CONVERSION TO ROWIDS 5 BITMAP OR 2 BITMAP CONVERSION FROM ROWIDS 1 INDEX RANGE SCAN INDEX AIDATINT.I_PRVVSSCHADENKORRESPONDENZ_1 Cost: 1 4 BITMAP CONVERSION FROM ROWIDS 3 INDEX RANGE SCAN INDEX AIDATINT.I_PRVVSSCHADENKORRESPONDENZ_2 Cost: 1I would have thought that as a plan as possible. It is not a concatenation, is a btree/bitmap conversion.
Allude to this plan you need / * + index_combine (table_alias index1 index2) * /.
For 10g and later the index can be specified by name or by descriptionI'm a bit puzzled why the plan changes after truncate - but maybe my comment about not cleared statistics is no longer true. It is easy enough to check if I'm right or wrong on your version of Oracle.
Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
Author: core Oracle -
Hello
I'm having the following problem.
I want to get a number of times that a clob field contains the words "(Indiscernible)", including the parenthesis. I am unable to do this.
Select SCORE (0), file name of t_transcripts
where contains (blob_content,
' < query >
< textquery lang = 'grammar' = "CTXCAT" > (indiscernible)
< / textquery >
< score datatype = "INTEGER" algorithm = "COUNT" / >
< / query > '
0) > 0;
The above query counts the Indiscernible Word, even when it occurs without the parenthesis. I tried to escape as follows
Select SCORE (0), file name of t_transcripts
where contains (blob_content,
' < query >
(< textquery lang = 'grammar' 'CTXCAT' = > \(indiscernible\)
< / textquery >
< score datatype = "INTEGER" algorithm = "COUNT" / >
< / query > '
0) > 0;
It always gives the same result. He counts the Indiscernible even when it occurs without the parenthesis.
How can I force to deal with the character (as (and not as a special character.
Thank you
AshokIf in doubt, test it and see. Your request has some syntax errors. For example, you have used 0 for the score for each of the three contained clauses. Once the errors have been corrected, it returns the results.
If you want to be able to search for {(Indiscernible).} and not get {(Indiscernible)} then, in addition to defining the period as a printjoin, you must remove the period as a punctuation by default. You can do this by defining the attribute scores with just the question mark and the exclamation point, omitting the period.
I'm guessing that you want to combine the scores. If so, then using multiple contains clauses is not the most effective method. It is best to use a contains clause.
You can use definescore with the appearance instead of a query with algorithm = count template. If you do this and add 'sort by order_id' to your index, then you can add 'and sdata (order_id = 34)' to your clause instead of having the "order_id = 34" as a separate where condition, resulting in more effective delivery.»
Please see the example below and note the differences in your original query execution plans has been corrected and the query suggested to the end, using filter by index and by the presence and surlabasedesdonneesdufabricantduballast definescore in him contains the clause.
Note: Definescore and surlabasedesdonneesdufabricantduballast are characteristic of 11g.
-table and data:
SCOTT@orcl_11gR2> create table t_notes 2 (order_id number, 3 blob_content blob) 4 / Table created. SCOTT@orcl_11gR2> insert all 2 into t_notes values (34, utl_raw.cast_to_raw ('Indiscernible')) 3 into t_notes values (34, utl_raw.cast_to_raw ('(Indiscernible)')) 4 into t_notes values (34, utl_raw.cast_to_raw ('(Indiscernible.)')) 5 into t_notes values (34, utl_raw.cast_to_raw ('(Indiscernible).')) 6 select * from dual 7 / 4 rows created.-lexer with printjoins and punctuation and index that uses lexer and chips resulting:
SCOTT@orcl_11gR2> begin 2 ctx_ddl.create_preference ('mylexer', 'basic_lexer'); 3 ctx_ddl.set_attribute ('mylexer', 'PRINTJOINS', '() :.'); 4 ctx_ddl.set_attribute ('mylexer', 'PUNCTUATIONS', '?!'); 5 end; 6 / PL/SQL procedure successfully completed. SCOTT@orcl_11gR2> create index t_notes_idx 2 on t_notes (blob_content) 3 indextype is ctxsys.context 4 parameters ('lexer mylexer') 5 / Index created. SCOTT@orcl_11gR2> select token_text from dr$t_notes_idx$i 2 / TOKEN_TEXT ---------------------------------------------------------------- (INDISCERNIBLE) (INDISCERNIBLE). (INDISCERNIBLE.) INDISCERNIBLE 4 rows selected.-original query with minor corrections after the collection of statistics:
SCOTT@orcl_11gR2> begin 2 dbms_stats.gather_table_stats (user, 'T_NOTES'); 3 end; 4 / PL/SQL procedure successfully completed. SCOTT@orcl_11gR2> column blob_content format a20 SCOTT@orcl_11gR2> set autotrace on explain SCOTT@orcl_11gR2> select utl_raw.cast_to_varchar2 (blob_content) blob_content, 2 order_id, SCORE(0) as c0, score(1) as c1, score(2) as c2, 3 score(0) + score(1) + score(2) as total_score 4 from t_notes 5 where order_id = 34 6 and (contains 7 (blob_content, 8 '9 ', 13 0) > 0 or 14 contains 15 (blob_content, 16 '{(Indiscernible)} 10 1112 17 ', 21 1) > 0 or 22 contains 23 (blob_content, 24 '{(Indiscernible.)} 18 1920 25 ', 29 2) > 0) 30 / BLOB_CONTENT ORDER_ID C0 C1 C2 TOTAL_SCORE -------------------- ---------- ---------- ---------- ---------- ----------- (Indiscernible) 34 1 0 0 1 (Indiscernible.) 34 0 1 0 1 (Indiscernible). 34 0 0 1 1 3 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 2000372820 ------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 2 | 66 | 6 (0)| 00:00:01 | |* 1 | TABLE ACCESS BY INDEX ROWID | T_NOTES | 2 | 66 | 6 (0)| 00:00:01 | | 2 | BITMAP CONVERSION TO ROWIDS | | | | | | | 3 | BITMAP OR | | | | | | | 4 | BITMAP CONVERSION FROM ROWIDS| | | | | | | 5 | SORT ORDER BY | | | | | | |* 6 | DOMAIN INDEX | T_NOTES_IDX | | | 0 (0)| 00:00:01 | | 7 | BITMAP CONVERSION FROM ROWIDS| | | | | | | 8 | SORT ORDER BY | | | | | | |* 9 | DOMAIN INDEX | T_NOTES_IDX | | | 0 (0)| 00:00:01 | | 10 | BITMAP CONVERSION FROM ROWIDS| | | | | | | 11 | SORT ORDER BY | | | | | | |* 12 | DOMAIN INDEX | T_NOTES_IDX | | | 0 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("ORDER_ID"=34) 6 - access("CTXSYS"."CONTAINS"("BLOB_CONTENT",'{(Indiscernible).} 26 2728 {(Indiscernible)} {(Indiscernible.)} {(Indiscernible).} {(Indiscernible.)} {(Indiscernible).} {(Indiscernible).} -suggestion for a more effective method using filter by and by the presence and surlabasedesdonneesdufabricantduballast definescore:
SCOTT@orcl_11gR2> drop index t_notes_idx 2 / Index dropped. SCOTT@orcl_11gR2> create index t_notes_idx 2 on t_notes (blob_content) 3 indextype is ctxsys.context 4 filter by order_id 5 parameters ('lexer mylexer') 6 / Index created. SCOTT@orcl_11gR2> select token_text from dr$t_notes_idx$i 2 / TOKEN_TEXT ---------------------------------------------------------------- (INDISCERNIBLE) (INDISCERNIBLE). (INDISCERNIBLE.) INDISCERNIBLE 4 rows selected. SCOTT@orcl_11gR2> begin 2 dbms_stats.gather_table_stats (user, 'T_NOTES'); 3 end; 4 / PL/SQL procedure successfully completed. SCOTT@orcl_11gR2> set autotrace on explain SCOTT@orcl_11gR2> select utl_raw.cast_to_varchar2 (blob_content) blob_content, 2 order_id, SCORE(0) as total_score 3 from t_notes 4 where contains 5 (blob_content, 6 'definescore 7 (({(Indiscernible)} OR {(Indiscernible.)} OR {(Indiscernible).}), 8 occurrence) and 9 sdata (order_id = 34)', 10 0) > 0 11 / BLOB_CONTENT ORDER_ID TOTAL_SCORE -------------------- ---------- ----------- (Indiscernible) 34 1 (Indiscernible.) 34 1 (Indiscernible). 34 1 3 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 198627995 ------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 33 | 0 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| T_NOTES | 1 | 33 | 0 (0)| 00:00:01 | |* 2 | DOMAIN INDEX | T_NOTES_IDX | | | 0 (0)| 00:00:01 | ------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("CTXSYS"."CONTAINS"("BLOB_CONTENT",'definescore (({(Indiscernible)} OR {(Indiscernible.)} OR {(Indiscernible).}), occurrence) and sdata (order_id = 34)',0)>0) SCOTT@orcl_11gR2> -
TIP, GOLD and the INDEX FUNCTION-ORIENTED
RDBMS: 10.1.0.5.0
I'm trying to force an index based on a function in a query with a condition OR .
It seems that INDEX INDICATOR does not work if the query has an OR condition.
I created a test case to describe the problem:
The plan of the explain for a simple query command is:create table tab1 (col1 VARCHAR2(300)) ....load the table....... CREATE INDEX col1_IX ON tab1 ( my_FUNCTION(col1) ) TABLESPACE USERS ;
If the simple query has a CONDITION or:select * from tab1 where my_FUNCTION(col1) = '+23452081' Plan hash value: 2179519467 --------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 871 | 512K| 2 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| TAB1 | 871 | 512K| 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | COL1_IX | 348 | | 1 (0)| 00:00:01 | --------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("my_FUNCTION"("COL1")='+23452081') Note ----- - dynamic sampling used for this statement
I tried to force the index using the trick without success:select * from tab1 where ( MY_FUNCTION(col1) = '+23452081' or col1 <> '') Plan hash value: 2211052296 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5183 | 3047K| 59 (31)| 00:00:01 | |* 1 | TABLE ACCESS FULL| TAB1 | 5183 | 3047K| 59 (31)| 00:00:01 | -------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("COL1"<>'' OR "MY_FUNCTION"("COL1")='+23452081') Note ----- - dynamic sampling used for this statement
Can you help me?select /*+ index(tab1 col1_IX) */ * from tab1 where ( MY_FUNCTION(col1) = '+23452081' or col1 <> '') Plan hash value: 2211052296 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5183 | 3047K| 59 (31)| 00:00:01 | |* 1 | TABLE ACCESS FULL| TAB1 | 5183 | 3047K| 59 (31)| 00:00:01 | -------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("COL1"<>'' OR "MY_FUNCTION"("COL1")='+23452081') Note ----- - dynamic sampling used for this statementPublished by: Dom Brooks on January 28, 2011 11:26
Sorry too hasty.
If you have an index on COL1 and your predicate can use this index, then you might get a BITMAP CONVERSION.
If you do not have an index on COL1 or you cannot use it, then you will do a FTS.
Useful relevant info:
Based on an index function are not used in the expansion of GOLD in 10gR 1 (or beyond - restriction still documented in 11 GR 2)
See here:
http://download.Oracle.com/docs/CD/B14117_01/AppDev.101/b10795/adfns_in.htm#1006464Dion Cho spoke here:
http://dioncho.WordPress.com/2009/07/31/function-based-index-and-or-expansion/ -
Consider a table (textable) with at least 2 fields.
1 field docid is long and is indexed. It is not unique.
Textclob field 2 is a Clob and contains text.
Queries
Select * from textable where contains (textclob, "DOG") > 0;
and
Select * from textable where docid = 12345 and contains (textclob, "DOG") > 0;
both take the same time to run even if first of all to limit the query to the docid relevatn will reduce the necessary lines text search
by orders of magnitude
How to evaluate the docid where before you start searching for the query textYou cannot create an index on a long data type, so I don't know what makes you think that the long column is indexed. Long columns are deprecated. For most of the things the long columns were used for, you must now use a clob column instead. For a digital ID column, you must use a number data type, which can then indexed. You must have current statistics so that the optimizer to choose the best execution plan. You can use dbms_stats.gather_table_stats to obtain these statistics, after having inserted your data and created your index. It is possible to use views inline and the index indicators, etc. to influence the optimizer, but generally the optimizer knows best.
In the example below, I made the docid one column type data number, inserted enough data for testing, created the index on two columns, allowing you to collect statistics, set the timing and autotrace on dbms_stats.gather_table_stats, ran both queries and the second ran faster, query using the index on the docid column first then the index on the textclob column.
SCOTT@orcl_11gR2> alter system flush shared_pool 2 / System altered. SCOTT@orcl_11gR2> create table textable 2 (docid number, 3 textclob Clob) 4 / Table created. SCOTT@orcl_11gR2> insert into textable values (12345, 'DOG') 2 / 1 row created. SCOTT@orcl_11gR2> insert into textable 2 select object_id, object_name 3 from all_objects 4 / 75596 rows created. SCOTT@orcl_11gR2> create index textable_docid_idx 2 on textable (docid) 3 / Index created. SCOTT@orcl_11gR2> create index textable_textclob_idx 2 on textable (textclob) 3 indextype is ctxsys.context 4 / Index created. SCOTT@orcl_11gR2> exec dbms_stats.gather_table_stats (user, 'TEXTABLE') PL/SQL procedure successfully completed. SCOTT@orcl_11gR2> set timing on SCOTT@orcl_11gR2> set autotrace on explain SCOTT@orcl_11gR2> Select * from textable where contains(textclob, 'DOG') >0 2 / DOCID ---------- TEXTCLOB ------------------------------------------------------------------------------------------------------------------------ 12345 DOG 1 row selected. Elapsed: 00:00:00.11 Execution Plan ---------------------------------------------------------- Plan hash value: 2944576608 ----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 155 | 0 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| TEXTABLE | 1 | 155 | 0 (0)| 00:00:01 | |* 2 | DOMAIN INDEX | TEXTABLE_TEXTCLOB_IDX | | | 0 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("CTXSYS"."CONTAINS"("TEXTCLOB",'DOG')>0) SCOTT@orcl_11gR2> Select * from textable where docid = 12345 and contains(textclob, 'DOG') >0 2 / DOCID ---------- TEXTCLOB ------------------------------------------------------------------------------------------------------------------------ 12345 DOG 1 row selected. Elapsed: 00:00:00.01 Execution Plan ---------------------------------------------------------- Plan hash value: 566902540 ---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 155 | 1 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID | TEXTABLE | 1 | 155 | 1 (0)| 00:00:01 | | 2 | BITMAP CONVERSION TO ROWIDS | | | | | | | 3 | BITMAP AND | | | | | | | 4 | BITMAP CONVERSION FROM ROWIDS| | | | | | | 5 | SORT ORDER BY | | | | | | |* 6 | DOMAIN INDEX | TEXTABLE_TEXTCLOB_IDX | 1 | | 0 (0)| 00:00:01 | | 7 | BITMAP CONVERSION FROM ROWIDS| | | | | | |* 8 | INDEX RANGE SCAN | TEXTABLE_DOCID_IDX | 1 | | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 6 - access("CTXSYS"."CONTAINS"("TEXTCLOB",'DOG')>0) 8 - access("DOCID"=12345) SCOTT@orcl_11gR2>
Maybe you are looking for
-
Tecra A11-125 - technical specification on the integrated chip
Hello Where can I find more info for the Tecra A11-125? Specifically, I need to know the SATA standard for the chip: is Sata150 and Sata300? Thank you Oliver
-
I'm looking for the RGB values of the PURPLE (private mode) Firefox Button?
Or TSL values? Thank you
-
How to restore administrative shares remotely
How to restore administrative shares (admin$, ipc$, etc) remotely in a domain environment Someone there a logon script, or can it be done via GPO? Any help is appreciated Thank you Freddie
-
I have a Pavilion notebook dv7-1175nr with a Blu - ray palyer player who does not play movies.
Initially, it came with Vista and a Blu - ray player. He recently had a facility fresh retail of Windows 7 Pro and all the drivers & software freshly downloaded and installed on the HP site. Since the Blu - ray drive upgrade is not play movies.
-
BlackBerry 10 Q10 does not level of 10.2
This is my first time ever in a 'tech' forum, so if the problem that I have an answer somewhere on this forum, please accept my appolgies in advance for not not looking more closely My OS Q10 is 10.1.0.4189. I tried to update the 10.2 since it was i