I am working to further optimize the following query. I have already had a lot of success optimizing the query up to this point, but now I am looking for help from others for ideas. I appreciate your help.
The following query takes over 200 seconds to complete yet the two individual WITH clause queries (receiving_1 and receiving_2) that make up the "UNION ALL" take less than 4 seconds each.
receiving_1 -- 58 recs in 3.4 secs; cost 295 (no UNION)
receiving_2 -- 0 recs in 3.8 secs; cost 295 (no UNION)
UNION ALL of 1+2 -- 58 recs in 203.1 secs; cost 300 (UNION ALL)
I was hoping "rownum" would help optimize the "UNION ALL", but it did not. This attempt was based on a note from AskTom --> Files --> SQLTechniques.zip (between 61 and 72)
When you have two queries that run light speed separately
But not so together
Generally a mixed “CBO/RBO” problem
Use of RBO with a feature that kicks in the CBO
Rownum can be a temporary fix till all things are CBO
NOTE: One optimization that avoids this issue is embedded replacement parameters or cursor parameters that greatly reduce the rows at key points in the query. However, because I need to run this query through a database link against a read-only database, the following options are not available for this query.
dbms_sql over database link: query is too long; dbs_sql does not accept a lob over database link; also DBAs don't allow the running of any PL/SQL in the read-only database.
pipelined function: pipelined function has known bug over database link between 19c and 11g so fails
sys_refcursor via PL/SQL: cursors are not supported over database links
set parameter values in PL/SQL package and use them in view: not allowed to execute any code in read-only database (I am still bugging the DBAs to allow this. This might be my best hope if I am not able to optimize the below query to run as a view.)
NOTE: In an attempt at providing a good test case with as little code as possible, the below SQL (4,584 chars, 88 line breaks) is a greatly simplified version of the actual SQL (93,683 chars, 2,014 line breaks) I am developing. The original SQL has already gone through several rounds of optimizations to bring the runtime down from over an hour to under 10 seconds. This latest challenge is that the SQL has to be rewritten as a view as opposed to a SQL file with embedded substitution parameters. The substitution parameters were key to the optimizations up to now. I am now refactoring the SQL to work as a view in Oracle 11gR2 to be called via a database link from Oracle 19c. A view has no parameters, obviously. The driving parameters (ledger, OU, period) will be WHERE clause conditions when querying the view.
Big picture: The actual SQL under development is an amalgamation of 6 report queries that share a lot of duplicated code. My work is to convert all six source report queries into an efficient extract for importing into a new database schema for reconciliation purposes.
with
gccs as (
select
gcc.code_combination_id
from apps.gl_code_combinations gcc
where 1=1
AND regexp_like(gcc.segment1,'^[0-9]{4}$') -- only include 4-digit numbers
AND gcc.segment1 BETWEEN to_char('1500') and to_char('1504')
AND regexp_like(gcc.segment3,'^[0-9]{4}$') -- only include 4-digit numbers
AND ( gcc.segment3 BETWEEN to_char('5000') and to_char('5999')
OR gcc.segment3 in ('6000','6002','6003','6004','6005','6006','6007','6008','6009','6010','6011','6012','6013','6014','6017','6018','6019','6020','6021','6022','6023','6024','6025','6026','6027','6028','6029','6030','6031','6032',
'6033','6034','6035','6036','6037','6038','6039','6040','6041','6042','6043','6044','6045','6046','6047','6048','6049','6050','6051','6052','6053','6054','6055','6056','6058','6060','6061','6062','6063','6064',
'6065','6066','6067','6068','6069','6070','6071','6072','6073','6074','6075','6076','6077','6084','6085','6086','6087','6088','6089','6090','6091','6092','6093','6094','6095','6096','6097','6098','6099','6100',
'6101','6102','6103','6104','6105','6106','6120','6121','6130','6131','6140','6150','6151','6155','6158','6162','6990','6991','6992','6993','6994','6995','6996','6997','6998'))
AND regexp_like(gcc.segment6,'^[0-9]{4}$') -- only include 4-digit numbers
AND gcc.segment6 BETWEEN to_char('3000') and to_char('4999')
) -- select count(*) code_combination_id from gccs;
,
base_query as (
SELECT
gl.LEDGER_ID,
hou.organization_id,
gper.PERIOD_NAME,
XAL.AE_HEADER_ID,
XAL.AE_LINE_NUM,
GJB.STATUS BATCH_STATUS,
GJH.JE_CATEGORY,
XAL.ACCOUNTING_CLASS_CODE,
GJH.JE_SOURCE,
GJH.JE_HEADER_ID,
GJL.JE_LINE_NUM
FROM apps.gl_ledgers gl
join apps.hr_operating_units hou
on hou.set_of_books_id = gl.ledger_id
join APPS.GL_JE_LINES GJL
on exists (select null from gccs where gccs.CODE_COMBINATION_ID = GJL.CODE_COMBINATION_ID)
AND (nvl(gjl.stat_amount,0) <> 0 OR (NVL (gjl.accounted_dr, 0) - NVL (gjl.accounted_cr, 0)) <> 0)
join APPS.GL_PERIODS gper
on GJL.PERIOD_NAME = gper.PERIOD_NAME
join APPS.GL_JE_HEADERS GJH
on GJH.JE_HEADER_ID = GJL.JE_HEADER_ID
AND GJH.PERIOD_NAME = gper.PERIOD_NAME
AND GJH.LEDGER_ID = gl.ledger_id
AND GJH.JE_SOURCE = 'Cost Management'
join APPS.GL_JE_BATCHES GJB
on GJB.JE_BATCH_ID = GJH.JE_BATCH_ID
join APPS.GL_IMPORT_REFERENCES GIR
on GIR.JE_HEADER_ID = GJL.JE_HEADER_ID
AND GIR.JE_LINE_NUM = GJL.JE_LINE_NUM
join APPS.XLA_AE_LINES XAL
on XAL.GL_SL_LINK_TABLE = GIR.GL_SL_LINK_TABLE
AND XAL.GL_SL_LINK_ID = GIR.GL_SL_LINK_ID
AND XAL.LEDGER_ID = gl.LEDGER_ID
),
receiving_1 as (
select distinct
bq.LEDGER_ID,
bq.organization_id,
bq.period_name,
bq.AE_HEADER_ID,
bq.AE_LINE_NUM
FROM base_query bq
WHERE bq.BATCH_STATUS = 'P'
AND UPPER(bq.JE_CATEGORY) = UPPER('Receiving')
),
receiving_2 as (
select distinct
bq.LEDGER_ID,
bq.organization_id,
bq.period_name,
bq.AE_HEADER_ID,
bq.AE_LINE_NUM
FROM base_query bq
WHERE bq.ACCOUNTING_CLASS_CODE = 'INTRA'
AND bq.BATCH_STATUS = 'P'
AND UPPER(bq.JE_CATEGORY) = UPPER('Receiving')
),
receiving_all as (
-- the use of "rownum" below sometimes helps to optimize "union all", but does not help in this query
select rownum, x.* from receiving_1 x -- 58 recs in 3.4 secs cost 295 (no UNION)
union all -- 58 recs in 203.1 secs cost 300 (UNION ALL)
select rownum, x.* from receiving_2 x -- 0 recs in 3.8 secs cost 295 (no UNION)
)
select count(*)
from receiving_all
where ledger_id = 2021
and organization_id = 82
and period_name = 'SEP-2020';
AUTOTRACE for receiving_1 part of query"
COUNT(*)
----------
58
Execution Plan
----------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 35 | 295 (1)| | |
| 1 | SORT AGGREGATE | | 1 | 35 | | | |
| 2 | VIEW | | 1 | 35 | 295 (1)| | |
| 3 | COUNT | | | | | | |
| 4 | VIEW | | 1 | 35 | 295 (1)| | |
| 5 | HASH UNIQUE | | 1 | 266 | 295 (1)| | |
| 6 | NESTED LOOPS | | 1 | 266 | 294 (1)| | |
| 7 | NESTED LOOPS | | 1 | 266 | 294 (1)| | |
| 8 | NESTED LOOPS | | 1 | 237 | 236 (1)| | |
| 9 | NESTED LOOPS | | 1 | 214 | 178 (1)| | |
| 10 | NESTED LOOPS | | 1 | 207 | 176 (1)| | |
| 11 | NESTED LOOPS | | 1 | 183 | 176 (1)| | |
| 12 | NESTED LOOPS | | 1 | 152 | 173 (1)| | |
| 13 | NESTED LOOPS | | 1 | 148 | 173 (1)| | |
| 14 | NESTED LOOPS | | 1 | 123 | 172 (1)| | |
| 15 | NESTED LOOPS | | 1 | 101 | 169 (1)| | |
| 16 | NESTED LOOPS | | 1 | 97 | 169 (1)| | |
| 17 | NESTED LOOPS | | 1 | 53 | 167 (1)| | |
| 18 | SORT UNIQUE | | 1 | 21 | 22 (0)| | |
| 19 | TABLE ACCESS BY INDEX ROWID| GL_CODE_COMBINATIONS | 1 | 21 | 22 (0)| | |
| 20 | INDEX RANGE SCAN | GL_CODE_COMBINATIONS_N1 | 117 | | 8 (0)| | |
| 21 | TABLE ACCESS BY INDEX ROWID | GL_JE_LINES | 16 | 512 | 144 (0)| | |
| 22 | INDEX RANGE SCAN | GL_JE_LINES_N1 | 319 | | 4 (0)| | |
| 23 | TABLE ACCESS BY INDEX ROWID | GL_JE_HEADERS | 1 | 44 | 2 (0)| | |
| 24 | INDEX UNIQUE SCAN | GL_JE_HEADERS_U1 | 1 | | 1 (0)| | |
| 25 | INDEX UNIQUE SCAN | GL_LEDGERS_U2 | 1 | 4 | 0 (0)| | |
| 26 | TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION | 1 | 22 | 3 (0)| | |
| 27 | INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK1 | 30 | | 1 (0)| | |
| 28 | INDEX RANGE SCAN | GL_PERIODS_U1 | 1 | 25 | 1 (0)| | |
| 29 | INDEX UNIQUE SCAN | HR_ORGANIZATION_UNITS_PK | 1 | 4 | 0 (0)| | |
| 30 | TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION | 1 | 31 | 3 (0)| | |
| 31 | INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK2 | 2 | | 1 (0)| | |
| 32 | INDEX UNIQUE SCAN | HR_ALL_ORGANIZATION_UNTS_TL_PK | 1 | 24 | 0 (0)| | |
| 33 | TABLE ACCESS BY INDEX ROWID | GL_JE_BATCHES | 1 | 7 | 2 (0)| | |
| 34 | INDEX UNIQUE SCAN | GL_JE_BATCHES_U1 | 1 | | 1 (0)| | |
| 35 | TABLE ACCESS BY INDEX ROWID | GL_IMPORT_REFERENCES | 105 | 2415 | 58 (0)| | |
| 36 | INDEX RANGE SCAN | GL_IMPORT_REFERENCES_N1 | 105 | | 3 (0)| | |
| 37 | PARTITION LIST ALL | | 1 | | 57 (0)| 1 | 19 |
| 38 | INDEX RANGE SCAN | XLA_AE_LINES_N4 | 1 | | 57 (0)| 1 | 19 |
| 39 | TABLE ACCESS BY LOCAL INDEX ROWID | XLA_AE_LINES | 1 | 29 | 58 (0)| 1 | 1 |
-------------------------------------------------------------------------------------------------------------------------------------
Note
-----
- 'PLAN_TABLE' is old version
Statistics
----------------------------------------------------------
99 recursive calls
0 db block gets
3500320 consistent gets
0 physical reads
116 redo size
346 bytes sent via SQL*Net to client
4388 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
AUTOTRACE for receiving_2 part of query:
COUNT(*)
----------
0
Execution Plan
----------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 35 | 295 (1)| | |
| 1 | SORT AGGREGATE | | 1 | 35 | | | |
| 2 | VIEW | | 1 | 35 | 295 (1)| | |
| 3 | COUNT | | | | | | |
| 4 | VIEW | | 1 | 35 | 295 (1)| | |
| 5 | HASH UNIQUE | | 1 | 279 | 295 (1)| | |
| 6 | NESTED LOOPS | | 1 | 279 | 294 (1)| | |
| 7 | NESTED LOOPS | | 1 | 279 | 294 (1)| | |
| 8 | NESTED LOOPS | | 1 | 272 | 292 (1)| | |
| 9 | NESTED LOOPS | | 1 | 230 | 234 (1)| | |
| 10 | NESTED LOOPS | | 1 | 207 | 176 (1)| | |
| 11 | NESTED LOOPS | | 1 | 183 | 176 (1)| | |
| 12 | NESTED LOOPS | | 1 | 152 | 173 (1)| | |
| 13 | NESTED LOOPS | | 1 | 148 | 173 (1)| | |
| 14 | NESTED LOOPS | | 1 | 126 | 170 (1)| | |
| 15 | NESTED LOOPS | | 1 | 122 | 170 (1)| | |
| 16 | NESTED LOOPS | | 1 | 97 | 169 (1)| | |
| 17 | NESTED LOOPS | | 1 | 53 | 167 (1)| | |
| 18 | SORT UNIQUE | | 1 | 21 | 22 (0)| | |
| 19 | TABLE ACCESS BY INDEX ROWID| GL_CODE_COMBINATIONS | 1 | 21 | 22 (0)| | |
| 20 | INDEX RANGE SCAN | GL_CODE_COMBINATIONS_N1 | 117 | | 8 (0)| | |
| 21 | TABLE ACCESS BY INDEX ROWID | GL_JE_LINES | 16 | 512 | 144 (0)| | |
| 22 | INDEX RANGE SCAN | GL_JE_LINES_N1 | 319 | | 4 (0)| | |
| 23 | TABLE ACCESS BY INDEX ROWID | GL_JE_HEADERS | 1 | 44 | 2 (0)| | |
| 24 | INDEX UNIQUE SCAN | GL_JE_HEADERS_U1 | 1 | | 1 (0)| | |
| 25 | INDEX RANGE SCAN | GL_PERIODS_U1 | 1 | 25 | 1 (0)| | |
| 26 | INDEX UNIQUE SCAN | GL_LEDGERS_U2 | 1 | 4 | 0 (0)| | |
| 27 | TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION | 1 | 22 | 3 (0)| | |
| 28 | INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK1 | 30 | | 1 (0)| | |
| 29 | INDEX UNIQUE SCAN | HR_ORGANIZATION_UNITS_PK | 1 | 4 | 0 (0)| | |
| 30 | TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION | 1 | 31 | 3 (0)| | |
| 31 | INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK2 | 2 | | 1 (0)| | |
| 32 | INDEX UNIQUE SCAN | HR_ALL_ORGANIZATION_UNTS_TL_PK | 1 | 24 | 0 (0)| | |
| 33 | TABLE ACCESS BY INDEX ROWID | GL_IMPORT_REFERENCES | 105 | 2415 | 58 (0)| | |
| 34 | INDEX RANGE SCAN | GL_IMPORT_REFERENCES_N1 | 105 | | 3 (0)| | |
| 35 | PARTITION LIST ALL | | 1 | 42 | 58 (0)| 1 | 19 |
| 36 | TABLE ACCESS BY LOCAL INDEX ROWID | XLA_AE_LINES | 1 | 42 | 58 (0)| 1 | 19 |
| 37 | INDEX RANGE SCAN | XLA_AE_LINES_N4 | 1 | | 57 (0)| 1 | 19 |
| 38 | INDEX UNIQUE SCAN | GL_JE_BATCHES_U1 | 1 | | 1 (0)| | |
| 39 | TABLE ACCESS BY INDEX ROWID | GL_JE_BATCHES | 1 | 7 | 2 (0)| | |
-------------------------------------------------------------------------------------------------------------------------------------
Note
-----
- 'PLAN_TABLE' is old version
Statistics
----------------------------------------------------------
99 recursive calls
0 db block gets
3451912 consistent gets
0 physical reads
0 redo size
345 bytes sent via SQL*Net to client
4385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
AUTOTRACE for UNION ALL of full query that includes both request_1 and request_2
COUNT(*)
----------
58
Execution Plan
----------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 35 | 300 (1)| | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | |
| 2 | LOAD AS SELECT | SYS_TEMP_0FD9D6767_FC3F7B00 | | | | | |
| 3 | NESTED LOOPS | | 1 | 279 | 294 (1)| | |
| 4 | NESTED LOOPS | | 1 | 279 | 294 (1)| | |
| 5 | NESTED LOOPS | | 1 | 237 | 236 (1)| | |
| 6 | NESTED LOOPS | | 1 | 214 | 178 (1)| | |
| 7 | NESTED LOOPS | | 1 | 207 | 176 (1)| | |
| 8 | NESTED LOOPS | | 1 | 183 | 176 (1)| | |
| 9 | NESTED LOOPS | | 1 | 152 | 173 (1)| | |
| 10 | NESTED LOOPS | | 1 | 148 | 173 (1)| | |
| 11 | NESTED LOOPS | | 1 | 126 | 170 (1)| | |
| 12 | NESTED LOOPS | | 1 | 122 | 170 (1)| | |
| 13 | NESTED LOOPS | | 1 | 78 | 168 (1)| | |
| 14 | NESTED LOOPS | | 1 | 53 | 167 (1)| | |
| 15 | SORT UNIQUE | | 1 | 21 | 22 (0)| | |
| 16 | TABLE ACCESS BY INDEX ROWID| GL_CODE_COMBINATIONS | 1 | 21 | 22 (0)| | |
| 17 | INDEX RANGE SCAN | GL_CODE_COMBINATIONS_N1 | 117 | | 8 (0)| | |
| 18 | TABLE ACCESS BY INDEX ROWID | GL_JE_LINES | 16 | 512 | 144 (0)| | |
| 19 | INDEX RANGE SCAN | GL_JE_LINES_N1 | 319 | | 4 (0)| | |
| 20 | INDEX RANGE SCAN | GL_PERIODS_U1 | 1 | 25 | 1 (0)| | |
| 21 | TABLE ACCESS BY INDEX ROWID | GL_JE_HEADERS | 1 | 44 | 2 (0)| | |
| 22 | INDEX UNIQUE SCAN | GL_JE_HEADERS_U1 | 1 | | 1 (0)| | |
| 23 | INDEX UNIQUE SCAN | GL_LEDGERS_U2 | 1 | 4 | 0 (0)| | |
| 24 | TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION | 1 | 22 | 3 (0)| | |
| 25 | INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK1 | 30 | | 1 (0)| | |
| 26 | INDEX UNIQUE SCAN | HR_ORGANIZATION_UNITS_PK | 1 | 4 | 0 (0)| | |
| 27 | TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION | 1 | 31 | 3 (0)| | |
| 28 | INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK2 | 2 | | 1 (0)| | |
| 29 | INDEX UNIQUE SCAN | HR_ALL_ORGANIZATION_UNTS_TL_PK | 1 | 24 | 0 (0)| | |
| 30 | TABLE ACCESS BY INDEX ROWID | GL_JE_BATCHES | 1 | 7 | 2 (0)| | |
| 31 | INDEX UNIQUE SCAN | GL_JE_BATCHES_U1 | 1 | | 1 (0)| | |
| 32 | TABLE ACCESS BY INDEX ROWID | GL_IMPORT_REFERENCES | 105 | 2415 | 58 (0)| | |
| 33 | INDEX RANGE SCAN | GL_IMPORT_REFERENCES_N1 | 105 | | 3 (0)| | |
| 34 | PARTITION LIST ALL | | 1 | | 57 (0)| 1 | 19 |
| 35 | INDEX RANGE SCAN | XLA_AE_LINES_N4 | 1 | | 57 (0)| 1 | 19 |
| 36 | TABLE ACCESS BY LOCAL INDEX ROWID | XLA_AE_LINES | 1 | 42 | 58 (0)| 1 | 1 |
| 37 | SORT AGGREGATE | | 1 | 35 | | | |
| 38 | VIEW | | 2 | 70 | 6 (34)| | |
| 39 | UNION-ALL | | | | | | |
| 40 | COUNT | | | | | | |
| 41 | VIEW | | 1 | 35 | 3 (34)| | |
| 42 | HASH UNIQUE | | 1 | 44 | 3 (34)| | |
| 43 | VIEW | | 1 | 44 | 2 (0)| | |
| 44 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6767_FC3F7B00 | 1 | 74 | 2 (0)| | |
| 45 | COUNT | | | | | | |
| 46 | VIEW | | 1 | 35 | 3 (34)| | |
| 47 | HASH UNIQUE | | 1 | 61 | 3 (34)| | |
| 48 | VIEW | | 1 | 61 | 2 (0)| | |
| 49 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6767_FC3F7B00 | 1 | 74 | 2 (0)| | |
----------------------------------------------------------------------------------------------------------------------------------
Note
-----
- 'PLAN_TABLE' is old version
Statistics
----------------------------------------------------------
766 recursive calls
83076 db block gets
270487689 consistent gets
81660 physical reads
676 redo size
346 bytes sent via SQL*Net to client
4582 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
As I don't know the underlying tables, their structure and their data, I can only guess. Having said that, I'd try the following things (not knowing if any of the steps are helpful or not!):
remove the rownum from receiving_all
add the where clause from the main query to each of the subqueries in receiving_all. The optimizer might be able to infer this, but I am not sure.
change union all to union in receiving_all and remove the distinct from receiving_1 and receiving_2
receiving_2 seems to be included in receiving_2?
If 4. is not the case, I would combine both into a single query with WHERE UPPER(bq.JE_CATEGORY) = UPPER('Receiving') AND ( (<conditions for 1>) OR (<conditions for 2>) )
I would try if UPPER(bq.JE_CATEGORY) can be avoided. Functions prevent index access.
In case you can create tables, I'd unroll the values of gccs into two tables, one for segment_1, and another table for segment_2.
If 7. is not an option, I'd add the hint select /*+ materialize */ gcc.code_combination_id to gcc.
I'm very curious to see which suggestion has any positive impact...
I have a SQL statement that has performance issues.
Adding the following index and a SQL hint to use the index improves the performance 10 fold but I do not understand why.
BUS_ID is part of the primary key(T1.REF is the other part fo the key) and clustered index on the T1 table.
The T1 table has about 100,000 rows. BUS_ID has only 6 different values. Similarly the T1.STATUS column can only have a limited number of
possibilities and the majority of these(99%) will be the same value.
If I run the query without the hint(/*+ INDEX ( T1 T1_IDX1) NO_UNNEST */) it takes 5 seconds and with the hint it takes .5 seconds.
I don't understand how the index helps the subquery as T1.STATUS isn't used in any of the 'where' or 'join' clauses in the subquery.
What am I missing?
SELECT
/*+ NO_UNNEST */
t1.bus_id,
t1.ref,
t2.cust,
t3.cust_name,
t2.po_number,
t1.status_old,
t1.status,
t1.an_status
FROM t1
LEFT JOIN t2
ON t1.bus_id = t2.bus_id
AND t1.ref = t2.ref
JOIN t3
ON t3.cust = t2.cust
AND t3.bus_id = t2.bus_id
WHERE (
status IN ('A', 'B', 'C') AND status_old IN ('X', 'Y'))
AND EXISTS
( SELECT /*+ INDEX ( T1 T1_IDX1) NO_UNNEST */
*
FROM t1
WHERE ( EXISTS ( SELECT /*+ NO_UNNEST */
*
FROM t6
WHERE seq IN ( '0', '2' )
AND t1.bus_id = t6.bus_id)
OR (EXISTS
(SELECT /*+ NO_UNNEST */
*
FROM t6
WHERE seq = '1'
AND (an_status = 'Y'
OR
an_status = 'X')
AND t1.bus_id = t6.bus_id))
AND t2.ref = t1.ref))
AND USER IN ('FRED')
AND ( t2.status != '45'
AND t2.status != '20')
AND NOT EXISTS ( SELECT
/*+ NO_UNNEST */
*
FROM t4
WHERE EXISTS
(
SELECT
/*+ NO_UNNEST */
*
FROM t5
WHERE pd IN ( '1',
'0' )
AND appl = 'RYP'
AND appl_id IN ( 'RL100')
AND t4.id = t5.id)
AND t2.ref = p.ref
AND t2.bus_id = p.bus_id);
Edited to include Explain Plan and index.
Without Index hint
------------------------------------------------------|-------------------------------------
Operation | Options |Cost| # |Bytes | CPU Cost | IO COST
------------------------------------------------------|-------------------------------------
select statement | | 20 | 1 | 211 | 15534188 | 19 |
view | | 20 | 1 | 211 | 15534188 | 19 |
count | | | | | | |
view | | 20 | 1 | 198 | 15534188 | 19 |
sort | ORDER BY | 20 | 1 | 114 | 15534188 | 19 |
nested loops | | 7 | 1 | 114 | 62487 | 7 |
nested loops | | 7 | 1 | 114 | 62487 | 7 |
nested loops | | 6 | 1 | 84 | 53256 | 6 |
inlist iterator | | | | | | |
TABLE access t1 | INDEX ROWID | 4 | 1 | 29 | 36502 | 4 |
index-t1_idx#3 | RANGE SCAN | 3 | 1 | | 28686 | 3 |
TABLE access - t2 | INDEX ROWID | 2 | 1 | 55 | 16754 | 2 |
index t2_idx#0 | UNIQUE SCAN | 1 | 1 | | 9042 | 1 |
filter | | | | | | |
TABLE access-t1 | INDEX ROWID | 2 | 1 | 15 | 7433 | 2 |
TABLE access-t6 | INDEX ROWID | 3 | 1 | 4 | 23169 | 3 |
index-t6_idx#0 | UNIQUE RANGE SCAN | 1 | 3 | | 7721 | 1 |
filter | | | | | | |
TABLE access-t6 | INDEX ROWID | 2 | 2 | 8 | 15363 | 2 |
index-t6_idx#0 | UNIQUE RANGE SCAN | 1 | 3 | | 7521 | 1 |
index-t4_idx#1 | RANGE SCAN | 3 | 1 | 28 | 21584 | 3 |
inlist iterator | | | | | | |
index-t5_idx#1 | RANGE SCAN | 4 | 1 | 24 | 42929 | 4 |
index-t3_idx#0 | INDEX UNIQUE SCAN | 0 | 1 | | 1900 | 0 |
TABLE access-t3 | INDEX ROWID | 1 | 1 | 30 | 9231 | 1 |
--------------------------------------------------------------------------------------------
With Index hint
------------------------------------------------------|-------------------------------------
Operation | Options |Cost| # |Bytes | CPU Cost | IO COST
------------------------------------------------------|-------------------------------------
select statement | | 21 | 1 | 211 | 15549142 | 19 |
view | | 21 | 1 | 211 | 15549142 | 19 |
count | | | | | | |
view | | 21 | 1 | 198 | 15549142 | 19 |
sort | ORDER BY | 21 | 1 | 114 | 15549142 | 19 |
nested loops | | 7 | 1 | 114 | 62487 | 7 |
nested loops | | 7 | 1 | 114 | 62487 | 7 |
nested loops | | 6 | 1 | 84 | 53256 | 6 |
inlist iterator | | | | | | |
TABLE access t1 | INDEX ROWID | 4 | 1 | 29 | 36502 | 4 |
index-t1_idx#3 | RANGE SCAN | 3 | 1 | | 28686 | 3 |
TABLE access - t2 | INDEX ROWID | 2 | 1 | 55 | 16754 | 2 |
index t2_idx#0 | UNIQUE SCAN | 1 | 1 | | 9042 | 1 |
filter | | | | | | |
TABLE access-t1 | INDEX ROWID | 3 | 1 | 15 | 22387 | 2 |
index-t1_idx#1 | FULL SCAN | 2 |97k| | 14643 | |
TABLE access-t6 | INDEX ROWID | 3 | 1 | 4 | 23169 | 3 |
index-t6_idx#0 | UNIQUE RANGE SCAN | 1 | 3 | | 7721 | 1 |
filter | | | | | | |
TABLE access-t6 | INDEX ROWID | 2 | 2 | 8 | 15363 | 2 |
index-t6_idx#0 | UNIQUE RANGE SCAN | 1 | 3 | | 7521 | 1 |
index-t4_idx#1 | RANGE SCAN | 3 | 1 | 28 | 21584 | 3 |
inlist iterator | | | | | | |
index-t5_idx#1 | RANGE SCAN | 4 | 1 | 24 | 42929 | 4 |
index-t3_idx#0 | INDEX UNIQUE SCAN | 0 | 1 | | 1900 | 0 |
TABLE access-t3 | INDEX ROWID | 1 | 1 | 30 | 9231 | 1 |
--------------------------------------------------------------------------------------------
Table Index
CREATE INDEX T1_IDX#1 ON T1 (BUS_ID, STATUS)
I cannot figure out why sometimes, the total cost of a plan can be a very small number whereas looking inside the plan we can find huge costs. (indeed the query is very slow).
Can somebody explain me that?
Here is an example.
Apparently the costful part comes from a field in the main select that does a listagg on a subview and the join condition with this subview contains a complex condition (we can join on one field or another).
| Id | Operation | Name | Rows | Bytes | Cost |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 875 | 20 |
| 1 | SORT GROUP BY | | 1 | 544 | |
| 2 | VIEW | | 1 | 544 | 3 |
| 3 | SORT UNIQUE | | 1 | 481 | 3 |
| 4 | NESTED LOOPS | | | | |
| 5 | NESTED LOOPS | | 3 | 1443 | 2 |
| 6 | TABLE ACCESS BY INDEX ROWID | | 7 | 140 | 1 |
| 7 | INDEX RANGE SCAN | | 7 | | 1 |
| 8 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 9 | TABLE ACCESS BY INDEX ROWID | | 1 | 461 | 1 |
| 10 | SORT GROUP BY | | 1 | 182 | |
| 11 | NESTED LOOPS | | | | |
| 12 | NESTED LOOPS | | 8 | 1456 | 3 |
| 13 | NESTED LOOPS | | 8 | 304 | 2 |
| 14 | TABLE ACCESS BY INDEX ROWID | | 7 | 154 | 1 |
| 15 | INDEX RANGE SCAN | | 7 | | 1 |
| 16 | INDEX RANGE SCAN | | 1 | 16 | 1 |
| 17 | INDEX RANGE SCAN | | 1 | | 1 |
| 18 | TABLE ACCESS BY INDEX ROWID | | 1 | 144 | 1 |
| 19 | SORT GROUP BY | | 1 | 268 | |
| 20 | VIEW | | 1 | 268 | 9 |
| 21 | SORT UNIQUE | | 1 | 108 | 9 |
| 22 | CONCATENATION | | | | |
| 23 | NESTED LOOPS | | | | |
| 24 | NESTED LOOPS | | 1 | 108 | 4 |
| 25 | NESTED LOOPS | | 1 | 79 | 3 |
| 26 | NESTED LOOPS | | 1 | 59 | 2 |
| 27 | TABLE ACCESS BY INDEX ROWID | | 1 | 16 | 1 |
| 28 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 29 | TABLE ACCESS BY INDEX ROWID | | 1 | 43 | 1 |
| 30 | INDEX RANGE SCAN | | 1 | | 1 |
| 31 | TABLE ACCESS BY INDEX ROWID | | 1 | 20 | 1 |
| 32 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 33 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 34 | TABLE ACCESS BY INDEX ROWID | | 1 | 29 | 1 |
| 35 | NESTED LOOPS | | | | |
| 36 | NESTED LOOPS | | 1 | 108 | 4 |
| 37 | NESTED LOOPS | | 1 | 79 | 3 |
| 38 | NESTED LOOPS | | 1 | 59 | 2 |
| 39 | TABLE ACCESS BY INDEX ROWID | | 4 | 64 | 1 |
| 40 | INDEX RANGE SCAN | | 2 | | 1 |
| 41 | TABLE ACCESS BY INDEX ROWID | | 1 | 43 | 1 |
| 42 | INDEX RANGE SCAN | | 1 | | 1 |
| 43 | TABLE ACCESS BY INDEX ROWID | | 1 | 20 | 1 |
| 44 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 45 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 46 | TABLE ACCESS BY INDEX ROWID | | 1 | 29 | 1 |
| 47 | SORT GROUP BY | | 1 | 330 | |
| 48 | VIEW | | 1 | 330 | 26695 |
| 49 | SORT UNIQUE | | 1 | 130 | 26695 |
| 50 | CONCATENATION | | | | |
| 51 | HASH JOIN ANTI | | 1 | 130 | 13347 |
| 52 | NESTED LOOPS | | | | |
| 53 | NESTED LOOPS | | 1 | 110 | 4 |
| 54 | NESTED LOOPS | | 1 | 81 | 3 |
| 55 | NESTED LOOPS | | 1 | 61 | 2 |
| 56 | TABLE ACCESS BY INDEX ROWID | | 1 | 16 | 1 |
| 57 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 58 | TABLE ACCESS BY INDEX ROWID | | 1 | 45 | 1 |
| 59 | INDEX RANGE SCAN | | 1 | | 1 |
| 60 | TABLE ACCESS BY INDEX ROWID | | 1 | 20 | 1 |
| 61 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 62 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 63 | TABLE ACCESS BY INDEX ROWID | | 1 | 29 | 1 |
| 64 | VIEW | | 164K| 3220K| 13341 |
| 65 | NESTED LOOPS | | | | |
| 66 | NESTED LOOPS | | 164K| 11M| 13341 |
| 67 | NESTED LOOPS | | 164K| 8535K| 10041 |
| 68 | TABLE ACCESS BY INDEX ROWID | | 164K| 6924K| 8391 |
| 69 | INDEX SKIP SCAN | | 2131K| | 163 |
| 70 | INDEX UNIQUE SCAN | | 1 | 10 | 1 |
| 71 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 72 | TABLE ACCESS BY INDEX ROWID | | 1 | 20 | 1 |
| 73 | HASH JOIN ANTI | | 2 | 260 | 13347 |
| 74 | NESTED LOOPS | | | | |
| 75 | NESTED LOOPS | | 2 | 220 | 4 |
| 76 | NESTED LOOPS | | 2 | 162 | 3 |
| 77 | NESTED LOOPS | | 2 | 122 | 2 |
| 78 | TABLE ACCESS BY INDEX ROWID | | 4 | 64 | 1 |
| 79 | INDEX RANGE SCAN | | 2 | | 1 |
| 80 | TABLE ACCESS BY INDEX ROWID | | 1 | 45 | 1 |
| 81 | INDEX RANGE SCAN | | 1 | | 1 |
| 82 | TABLE ACCESS BY INDEX ROWID | | 1 | 20 | 1 |
| 83 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 84 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 85 | TABLE ACCESS BY INDEX ROWID | | 1 | 29 | 1 |
| 86 | VIEW | | 164K| 3220K| 13341 |
| 87 | NESTED LOOPS | | | | |
| 88 | NESTED LOOPS | | 164K| 11M| 13341 |
| 89 | NESTED LOOPS | | 164K| 8535K| 10041 |
| 90 | TABLE ACCESS BY INDEX ROWID | | 164K| 6924K| 8391 |
| 91 | INDEX SKIP SCAN | | 2131K| | 163 |
| 92 | INDEX UNIQUE SCAN | | 1 | 10 | 1 |
| 93 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 94 | TABLE ACCESS BY INDEX ROWID | | 1 | 20 | 1 |
| 95 | NESTED LOOPS OUTER | | 1 | 875 | 20 |
| 96 | NESTED LOOPS OUTER | | 1 | 846 | 19 |
| 97 | NESTED LOOPS OUTER | | 1 | 800 | 18 |
| 98 | NESTED LOOPS OUTER | | 1 | 776 | 17 |
| 99 | NESTED LOOPS OUTER | | 1 | 752 | 16 |
| 100 | NESTED LOOPS OUTER | | 1 | 641 | 15 |
| 101 | NESTED LOOPS OUTER | | 1 | 576 | 14 |
| 102 | NESTED LOOPS OUTER | | 1 | 554 | 13 |
| 103 | NESTED LOOPS OUTER | | 1 | 487 | 12 |
| 104 | NESTED LOOPS OUTER | | 1 | 434 | 11 |
| 105 | NESTED LOOPS | | 1 | 368 | 10 |
| 106 | NESTED LOOPS | | 1 | 102 | 9 |
| 107 | NESTED LOOPS OUTER | | 1 | 85 | 8 |
| 108 | NESTED LOOPS | | 1 | 68 | 7 |
| 109 | NESTED LOOPS | | 50 | 2700 | 6 |
| 110 | HASH JOIN | | 53 | 1696 | 5 |
| 111 | INLIST ITERATOR | | | | |
| 112 | TABLE ACCESS BY INDEX ROWID| | 520 | 10400 | 3 |
| 113 | INDEX RANGE SCAN | | 520 | | 1 |
| 114 | INLIST ITERATOR | | | | |
| 115 | TABLE ACCESS BY INDEX ROWID| | 91457 | 1071K| 1 |
| 116 | INDEX UNIQUE SCAN | | 2 | | 1 |
| 117 | TABLE ACCESS BY INDEX ROWID | | 1 | 22 | 1 |
| 118 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 119 | TABLE ACCESS BY INDEX ROWID | | 1 | 14 | 1 |
| 120 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 121 | TABLE ACCESS BY INDEX ROWID | | 1 | 17 | 1 |
| 122 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 123 | TABLE ACCESS BY INDEX ROWID | | 1 | 17 | 1 |
| 124 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 125 | TABLE ACCESS BY INDEX ROWID | | 1 | 266 | 1 |
| 126 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 127 | TABLE ACCESS BY INDEX ROWID | | 1 | 66 | 1 |
| 128 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 129 | TABLE ACCESS BY INDEX ROWID | | 1 | 53 | 1 |
| 130 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 131 | TABLE ACCESS BY INDEX ROWID | | 1 | 67 | 1 |
| 132 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 133 | INDEX RANGE SCAN | | 1 | 22 | 1 |
| 134 | TABLE ACCESS BY INDEX ROWID | | 1 | 65 | 1 |
| 135 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 136 | TABLE ACCESS BY INDEX ROWID | | 1 | 111 | 1 |
| 137 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 138 | TABLE ACCESS BY INDEX ROWID | | 1 | 24 | 1 |
| 139 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 140 | TABLE ACCESS BY INDEX ROWID | | 1 | 24 | 1 |
| 141 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 142 | TABLE ACCESS BY INDEX ROWID | | 1 | 46 | 1 |
| 143 | INDEX UNIQUE SCAN | | 1 | | 1 |
| 144 | TABLE ACCESS BY INDEX ROWID | | 1 | 29 | 1 |
| 145 | INDEX UNIQUE SCAN | | 1 | | 1 |
----------------------------------------------------------------------------------------------------------
The total cost of a statement is usually equal to or greater than the cost of any of its child operations. There are at least 4 exceptions to this rule.
Your plan looks like #3 but we can't be sure without looking at code.
1. FILTER
Execution plans may depend on conditions at run-time. These conditions cause FILTER operations that will dynamically decide which query block to execute. The example below uses a static condition but still demonstrates the concept. Part of the subquery is very expensive but the condition negates the whole thing.
explain plan for select * from dba_objects cross join dba_objects where 1 = 2;
select * from table(dbms_xplan.display(format => 'basic +cost'));
Plan hash value: 3258663795
--------------------------------------------------------------------
| Id | Operation | Name | Cost (%CPU)|
--------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 0 (0)|
| 1 | FILTER | | |
| 2 | MERGE JOIN CARTESIAN | | 11M (3)|
...
2. COUNT STOPKEY
Execution plans sum child operations up until the final cost. But child operations will not always finish. In the example below it may be correct to say that part of the plan costs 214. But because of the condition where rownum <= 1 only part of that child operation may run.
explain plan for
select /*+ no_query_transformation */ *
from (select * from dba_objects join dba_objects using (owner))
where rownum <= 1;
select * from table(dbms_xplan.display(format => 'basic +cost'));
Plan hash value: 2132093199
-------------------------------------------------------------------------------
| Id | Operation | Name | Cost (%CPU)|
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4 (0)|
| 1 | COUNT STOPKEY | | |
| 2 | VIEW | | 4 (0)|
| 3 | VIEW | | 4 (0)|
| 4 | NESTED LOOPS | | 4 (0)|
| 5 | VIEW | DBA_OBJECTS | 2 (0)|
| 6 | UNION-ALL | | |
| 7 | HASH JOIN | | 3 (34)|
| 8 | INDEX FULL SCAN | I_USER2 | 1 (0)|
| 9 | VIEW | _CURRENT_EDITION_OBJ | 1 (0)|
| 10 | FILTER | | |
| 11 | HASH JOIN | | 214 (3)|
...
3. Subqueries in the SELECT column list
Cost aggregation does not include subqueries in the SELECT column list. A query like select ([expensive query]) from dual; will have a very small total cost. I don't understand the reason for this; Oracle estimates the subquery and he number of rows in the FROM, surely it could multiply them together for a total cost.
explain plan for
select dummy,(select count(*) from dba_objects cross join dba_objects) from dual;
select * from table(dbms_xplan.display(format => 'basic +cost'));
Plan hash value: 3705842531
---------------------------------------------------------------
| Id | Operation | Name | Cost (%CPU)|
---------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 (0)|
| 1 | SORT AGGREGATE | | |
| 2 | MERGE JOIN CARTESIAN | | 11M (3)|
...
4. Other - rounding? bugs?
About 0.01% of plans still have unexplainable cost issues. I can't find any pattern among them. Perhaps it's just a rounding issue or some rare optimizer bugs. There will always be some weird cases with a any model as complicated as the optimizer.
Check for more exceptions
This query can find other exceptions, it returns all plans where the first cost is less than the maximum cost.
select *
from
(
--First and Max cost per plan.
select
sql_id, plan_hash_value, id, cost
,max(cost) keep (dense_rank first order by id)
over (partition by sql_id, plan_hash_value) first_cost
,max(cost)
over (partition by sql_id, plan_hash_value) max_cost
,max(case when operation = 'COUNT' and options = 'STOPKEY' then 1 else 0 end)
over (partition by sql_id, plan_hash_value) has_count_stopkey
,max(case when operation = 'FILTER' and options is null then 1 else 0 end)
over (partition by sql_id, plan_hash_value) has_filter
,count(distinct(plan_hash_value))
over () total_plans
from v$sql_plan
--where sql_id = '61a161nm1ttjj'
order by 1,2,3
)
where first_cost < max_cost
--It's easy to exclude FILTER and COUNT STOPKEY.
and has_filter = 0
and has_count_stopkey = 0
order by 1,2,3;
I want to generate a unique id in Oracle, it contains alphanumerics and length is 9-digits.
I tried,
==> select substr(sys_guid(),5,9) guid from dual;
will it have the unique nature?
please anyone help me out.
Thank u.
Seems to be overcomplicated when you cound just use a numeric sequence but you could do:
SQL Fiddle
Oracle 11g R2 Schema Setup:
CREATE OR REPLACE FUNCTION numberToAlnumString(
n IN NUMBER
) RETURN VARCHAR2
AS
i NUMBER := n;
s VARCHAR2(9);
r NUMBER(2,0);
BEGIN
WHILE i > 0 LOOP
r := MOD( i, 36 );
i := ( i - r ) / 36;
IF ( r < 10 ) THEN
s := TO_CHAR(r) || s;
ELSE
s := CHR( 55 + r ) || s;
END IF;
END LOOP;
RETURN LPAD( s, 9, '0' );
END;
/
CREATE SEQUENCE test__id__seq INCREMENT BY 1 START WITH 1
/
CREATE TABLE test (
id CHAR(9) NOT NULL,
name VARCHAR2(20)
)
/
CREATE OR REPLACE TRIGGER test_ins_trig
BEFORE INSERT ON test
FOR EACH ROW
BEGIN
:new.id := numberToAlnumString( test__id__seq.NEXTVAL );
END;
/
INSERT INTO test ( name )
SELECT TO_CHAR( LEVEL )
FROM DUAL
CONNECT BY LEVEL < 100
/
Query 1:
SELECT * FROM test
Results:
| ID | NAME |
|-----------|------|
| 000000001 | 1 |
| 000000002 | 2 |
| 000000003 | 3 |
| 000000004 | 4 |
| 000000005 | 5 |
| 000000006 | 6 |
| 000000007 | 7 |
| 000000008 | 8 |
| 000000009 | 9 |
| 00000000A | 10 |
| 00000000B | 11 |
| 00000000C | 12 |
| 00000000D | 13 |
| 00000000E | 14 |
| 00000000F | 15 |
| 00000000G | 16 |
| 00000000H | 17 |
| 00000000I | 18 |
| 00000000J | 19 |
| 00000000K | 20 |
| 00000000L | 21 |
| 00000000M | 22 |
| 00000000N | 23 |
| 00000000O | 24 |
| 00000000P | 25 |
| 00000000Q | 26 |
| 00000000R | 27 |
| 00000000S | 28 |
| 00000000T | 29 |
| 00000000U | 30 |
| 00000000V | 31 |
| 00000000W | 32 |
| 00000000X | 33 |
| 00000000Y | 34 |
| 00000000Z | 35 |
| 000000010 | 36 |
| 000000011 | 37 |
| 000000012 | 38 |
| 000000013 | 39 |
| 000000014 | 40 |
| 000000015 | 41 |
| 000000016 | 42 |
| 000000017 | 43 |
| 000000018 | 44 |
| 000000019 | 45 |
| 00000001A | 46 |
| 00000001B | 47 |
| 00000001C | 48 |
| 00000001D | 49 |
| 00000001E | 50 |
| 00000001F | 51 |
| 00000001G | 52 |
| 00000001H | 53 |
| 00000001I | 54 |
| 00000001J | 55 |
| 00000001K | 56 |
| 00000001L | 57 |
| 00000001M | 58 |
| 00000001N | 59 |
| 00000001O | 60 |
| 00000001P | 61 |
| 00000001Q | 62 |
| 00000001R | 63 |
| 00000001S | 64 |
| 00000001T | 65 |
| 00000001U | 66 |
| 00000001V | 67 |
| 00000001W | 68 |
| 00000001X | 69 |
| 00000001Y | 70 |
| 00000001Z | 71 |
| 000000020 | 72 |
| 000000021 | 73 |
| 000000022 | 74 |
| 000000023 | 75 |
| 000000024 | 76 |
| 000000025 | 77 |
| 000000026 | 78 |
| 000000027 | 79 |
| 000000028 | 80 |
| 000000029 | 81 |
| 00000002A | 82 |
| 00000002B | 83 |
| 00000002C | 84 |
| 00000002D | 85 |
| 00000002E | 86 |
| 00000002F | 87 |
| 00000002G | 88 |
| 00000002H | 89 |
| 00000002I | 90 |
| 00000002J | 91 |
| 00000002K | 92 |
| 00000002L | 93 |
| 00000002M | 94 |
| 00000002N | 95 |
| 00000002O | 96 |
| 00000002P | 97 |
| 00000002Q | 98 |
| 00000002R | 99 |
No, this approach will not have the unique nature.
if you want auto increment in your column value you can use Sequence for the this.
CREATE OR REPLACE SEQUENCE dept_seq
INCREMENT BY 1
START WITH 100000000
NOMAXVALUE
NOCYCLE
CACHE 10;
after creating sequence you can use After Insert Trigger to insert identical value.
here is trigger example...
CREATE OR REPLACE TRIGGER dep_ins_trig
BEFORE INSERT ON <table_name>
FOR EACH ROW
BEGIN
SELECT dept_seq.NEXTVAL
INTO :new.emp_id
FROM dual;
END;
/
---------------------------------------------------------------------------------------
Trigger and Sequence can be used when you want serialized (Auto Increment) number that anyone can easily read/remember/understand. But if you don't want to manage ID Column (like emp_id) by this way, and value of this column is not much considerable, you can use SYS_GUID() at Table Creation to get Auto Increment like this.
CREATE TABLE <table_name>
(emp_id RAW(16) DEFAULT SYS_GUID() PRIMARY KEY,
name VARCHAR2(30));
Now your emp_id column will accept "globally unique identifier value".
you can insert value in table by ignoring emp_id column like this.
INSERT INTO <table_name> (name) VALUES ('name value');
So, it will insert unique value to your emp_id Column.
Oracle has 2 functions - rank() and dense_rank() - which i've found very useful for some applications. I am doing something in mysql now and was wondering if they have something equivalent to those?
Nothing directly equivalent, but you can fake it with some (not terribly efficient) self-joins. Some sample code from a collection of MySQL query howtos:
SELECT v1.name, v1.votes, COUNT(v2.votes) AS Rank
FROM votes v1
JOIN votes v2 ON v1.votes < v2.votes OR (v1.votes=v2.votes and v1.name = v2.name)
GROUP BY v1.name, v1.votes
ORDER BY v1.votes DESC, v1.name DESC;
+-------+-------+------+
| name | votes | Rank |
+-------+-------+------+
| Green | 50 | 1 |
| Black | 40 | 2 |
| White | 20 | 3 |
| Brown | 20 | 3 |
| Jones | 15 | 5 |
| Smith | 10 | 6 |
+-------+-------+------+
how about this "dense_rank implement" in MySQL
CREATE TABLE `person` (
`id` int(11) DEFAULT NULL,
`first_name` varchar(20) DEFAULT NULL,
`age` int(11) DEFAULT NULL,
`gender` char(1) DEFAULT NULL);
INSERT INTO `person` VALUES
(1,'Bob',25,'M'),
(2,'Jane',20,'F'),
(3,'Jack',30,'M'),
(4,'Bill',32,'M'),
(5,'Nick',22,'M'),
(6,'Kathy',18,'F'),
(7,'Steve',36,'M'),
(8,'Anne',25,'F'),
(9,'Mike',25,'M');
the data before dense_rank() like this
mysql> select * from person;
+------+------------+------+--------+
| id | first_name | age | gender |
+------+------------+------+--------+
| 1 | Bob | 25 | M |
| 2 | Jane | 20 | F |
| 3 | Jack | 30 | M |
| 4 | Bill | 32 | M |
| 5 | Nick | 22 | M |
| 6 | Kathy | 18 | F |
| 7 | Steve | 36 | M |
| 8 | Anne | 25 | F |
| 9 | Mike | 25 | M |
+------+------------+------+--------+
9 rows in set (0.00 sec)
the data after dense_rank() like this,including "partition by" function
+------------+--------+------+------+
| first_name | gender | age | rank |
+------------+--------+------+------+
| Anne | F | 25 | 1 |
| Jane | F | 20 | 2 |
| Kathy | F | 18 | 3 |
| Steve | M | 36 | 1 |
| Bill | M | 32 | 2 |
| Jack | M | 30 | 3 |
| Mike | M | 25 | 4 |
| Bob | M | 25 | 4 |
| Nick | M | 22 | 6 |
+------------+--------+------+------+
9 rows in set (0.00 sec)
the query statement is
select first_name,t1.gender,age,FIND_IN_SET(age,t1.age_set) as rank from person t2,
(select gender,group_concat(age order by age desc) as age_set from person group by gender) t1
where t1.gender=t2.gender
order by t1.gender,rank