CBO generating Parallel Query on tables of Degree 1

In Oracle 9i release I have two tables which at one point in time were of degree 3. We have since changed these tables and their indexes back to degree 1 via ALTER TABLE ... PARALLEL (DEGREE 1) and ALTER INDEX ... PARALLEL (DEGREE 1). A query of DBA_TABLES and DBA_INDEXES verifies that the tables and their indexes are now degree 1. The database's OPTIMIZER_MODE is set to CHOOSE.
For some reason the EXPLAIN PLAN of a SELECT statement joining these tables is showing a parallel query. The tables are listed with an "@:Q279919001" postfixes to the table name. I believe that indicates the CBO is going to do a parallel query.
Why would the CBO choose a parallel query for tables which are degree 1?
Mike

try this
ALTER TABLE TAB PARALLEL (DEGREE 1 INSTANCES 1);
or
ALTER TABLE TAB NOPARALLEL;
Eugene Roytman

Similar Messages

Query in Table Maintanance Generator

Hi,
I have a query in table maintanance generator. In tables Extract and Total we have all the entries. Is it possible to get the entry which we made in the record. I mean i need the record in this i made the changes. I cant use above tqo tables because special characters are coming. Any body can suggest.
Regards,
Maheedhar

Maheedhar,
You will have to modify the program/code that was generated from the table maintenance generator to fit your requirements.
You can accomplish this by digging through the transport that you created, or by debugging through SM30 when you add a new entry or hit the save button. You should be able to find a place to add your custom logic.
Note: If you modify this code, anytime in the future if someone re-generates this table maintenance, your custom code will be over-written.
Thanks,
David

During Table Import got error ORA-12805: parallel query server died unexpectedly

Hi,
I tried to import a single table of size 51 GB which normally imported in 5 hours but last time I got following error after 1.5 hours
ORA-31693: Table data object "SCHEMA"."TABLE_NAME" failed to load/unload and is being skipped due to error:
ORA-12805: parallel query server died unexpectedly.
From the "Alert log" file I found the error is
ORA-00603: ORACLE server session terminated by fatal error
ORA-24557: error 1114 encountered while handling error 1114; exiting server process
ORA-01114: IO error writing block to file 622 (block # 373725)
ORA-27063: number of bytes read/written is incorrect
IBM AIX RISC System/6000 Error: 28: No space left on device
Additional information: -1
Additional information: 253952
I checked all the table spaces have more then 100GB free space. No idea why this happened.
Some mount points of the machine is 100% in used where the table spaces created but in table spaces auto extend is off on every data file and each data file have free space.
Anyone have idea how to resolve this issue.

Hi,
Which filesystem is file 622 in - it's quite a lrge numbered file - is it a tempfile or do you really have that many datafiles?
Regards,
Harry
http://dbaharrison.blogspot.com

CBO generating different plans for the same data in similar Environments

Hi All
I have been trying to compare an SQL from 2 different but similar environments build of the same hardware specs .The issue I am facing is environment A, the query executes in less than 2 minutes with plan mostly showing full table scans and hash join whereas in environment B(problematic), it times out after 2 hours with an error of unable to extend table space . The statistics are up to date in both environments for both tables and indexes . System parameters are exactly similar(default oracle for except for multiblock_read_count ).
Both Environment have same db parameter for db_file_multiblock_read_count(16), optimizer(refer below),hash_area_size (131072),pga_aggregate_target(1G),db_block_size(8192) etc . SREADTIM, MREADTIM, CPUSPEED, MBRC are all null in aux_stats in both environment because workload was never collected i believe.
Attached is details about the SQL with table stats, SQL and index stats my main concern is CBO generating different plans for the similar data and statistics and same hardware and software specs. Is there any thing else I should consider .I generally see environment B being very slow and always plans tend to nested loops and index scan whereas what we really need is a sensible FTS in many cases. One of the very surprising thing is METER_CONFIG_HEADER below which has just 80 blocks of data is being asked for index scan.
show parameter optimizer
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
**Environment**
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE     10.2.0.4.0     Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
Note: : There are slight difference in the no of records in the attached sheet.However, I wanted to tell that i have tested with exact same data and was getting similar results but I couldn't retain the data untill collecting the details in the attachment
TEST1     COMPARE TABLE LEVE STATS used by CBO
ENVIRONMENT A
TABLE_NAME     NUM_ROWS     BLOCKS     LAST_ANALYZED
ASSET     3607425     167760     5/02/2013 22:11
METER_CONFIG_HEADER     3658     80     5/01/2013 0:07
METER_CONFIG_ITEM     32310     496     5/01/2013 0:07
NMI     1899024     33557     18/02/2013 10:55
REGISTER     4830153     101504     18/02/2013 9:57
SDP_LOGICAL_ASSET     1607456     19137     18/02/2013 15:48
SDP_LOGICAL_REGISTER     5110781     78691     18/02/2013 9:56
SERVICE_DELIVERY_POINT     1425890     42468     18/02/2013 13:54
ENVIRONMENT B
TABLE_NAME     NUM_ROWS     BLOCKS     LAST_ANALYZED
ASSET     4133939     198570     16/02/2013 10:02
METER_CONFIG_HEADER     3779     80     16/02/2013 10:55
METER_CONFIG_ITEM     33720     510     16/02/2013 10:55
NMI     1969000     33113     16/02/2013 10:58
REGISTER     5837874     120104     16/02/2013 11:05
SDP_LOGICAL_ASSET     1788152     22325     16/02/2013 11:06
SDP_LOGICAL_REGISTER     6101934     91088     16/02/2013 11:07
SERVICE_DELIVERY_POINT     1447589     43804     16/02/2013 11:11
TEST ITEM 2     COMPARE INDEX STATS used by CBO
ENVIRONMENT A
TABLE_NAME     INDEX_NAME     UNIQUENESS     BLEVEL     LEAF_BLOCKS     DISTINCT_KEYS     AVG_LEAF_BLOCKS_PER_KEY     AVG_DATA_BLOCKS_PER_KEY     CLUSTERING_FACTOR     NUM_ROWS
ASSET     IDX_AST_DEVICE_CATEGORY_SK     NONUNIQUE     2     9878     67     147     12982     869801     3553095
ASSET     IDX_A_SAPINTLOGDEV_SK     NONUNIQUE     2     7291     2747     2     639     1755977     3597916
ASSET     SYS_C00102592     UNIQUE     2     12488     3733831     1     1     3726639     3733831
METER_CONFIG_HEADER     SYS_C0092052     UNIQUE     1     12     3670     1     1     3590     3670
METER_CONFIG_ITEM     SYS_C0092074     UNIQUE     1     104     32310     1     1     32132     32310
NMI     IDX_NMI_ID     NONUNIQUE     2     6298     844853     1     2     1964769     1965029
NMI     IDX_NMI_ID_NK     NONUNIQUE     2     6701     1923072     1     1     1922831     1923084
NMI     IDX_NMI_STATS     NONUNIQUE     1     106     4     26     52     211     211
REGISTER     REG_EFFECTIVE_DTM     NONUNIQUE     2     12498     795     15     2899     2304831     4711808
REGISTER     SYS_C00102653     UNIQUE     2     16942     5065660     1     1     5056855     5065660
SDP_LOGICAL_ASSET     IDX_SLA_SAPINTLOGDEV_SK     NONUNIQUE     2     3667     1607968     1     1     1607689     1607982
SDP_LOGICAL_ASSET     IDX_SLA_SDP_SK     NONUNIQUE     2     3811     668727     1     2     1606204     1607982
SDP_LOGICAL_ASSET     SYS_C00102665     UNIQUE     2     5116     1529606     1     1     1528136     1529606
SDP_LOGICAL_REGISTER     SYS_C00102677     UNIQUE     2     17370     5193638     1     1     5193623     5193638
SERVICE_DELIVERY_POINT     IDX_SDP_NMI_SK     NONUNIQUE     2     4406     676523     1     2     1423247     1425890
SERVICE_DELIVERY_POINT     IDX_SDP_SAP_INT_NMI_SK     NONUNIQUE     2     7374     676523     1     2     1458238     1461108
SERVICE_DELIVERY_POINT     SYS_C00102687     UNIQUE     2     4737     1416207     1     1     1415022     1416207
ENVIRONMENT B
TABLE_NAME     INDEX_NAME     UNIQUENESS     BLEVEL     LEAF_BLOCKS     DISTINCT_KEYS     AVG_LEAF_BLOCKS_PER_KEY     AVG_DATA_BLOCKS_PER_KEY     CLUSTERING_FACTOR     NUM_ROWS
ASSET     IDX_AST_DEVICE_CATEGORY_SK     NONUNIQUE     2     8606     121     71     16428     1987833     4162257
ASSET     IDX_A_SAPINTLOGDEV_SK     NONUNIQUE     2     8432     1780146     1     1     2048170     4162257
ASSET     SYS_C00116157     UNIQUE     2     13597     4162263     1     1     4158759     4162263
METER_CONFIG_HEADER     SYS_C00116570     UNIQUE     1     12     3779     1     1     3734     3779
METER_CONFIG_ITEM     SYS_C00116592     UNIQUE     1     107     33720     1     1     33459     33720
NMI     IDX_NMI_ID     NONUNIQUE     2     6319     683370     1     2     1970460     1971313
NMI     IDX_NMI_ID_NK     NONUNIQUE     2     6597     1971293     1     1     1970771     1971313
NMI     IDX_NMI_STATS     NONUNIQUE     1     98     48     2     4     196     196
REGISTER     REG_EFFECTIVE_DTM     NONUNIQUE     2     15615     1273     12     2109     2685924     5886582
REGISTER     SYS_C00116748     UNIQUE     2     19533     5886582     1     1     5845565     5886582
SDP_LOGICAL_ASSET     IDX_SLA_SAPINTLOGDEV_SK     NONUNIQUE     2     4111     1795084     1     1     1758441     1795130
SDP_LOGICAL_ASSET     IDX_SLA_SDP_SK     NONUNIQUE     2     4003     674249     1     2     1787987     1795130
SDP_LOGICAL_ASSET     SYS_C004520     UNIQUE     2     5864     1795130     1     1     1782147     1795130
SDP_LOGICAL_REGISTER     SYS_C004539     UNIQUE     2     20413     6152850     1     1     6073059     6152850
SERVICE_DELIVERY_POINT     IDX_SDP_NMI_SK     NONUNIQUE     2     3227     660649     1     2     1422572     1447803
SERVICE_DELIVERY_POINT     IDX_SDP_SAP_INT_NMI_SK     NONUNIQUE     2     6399     646257     1     2     1346948     1349993
SERVICE_DELIVERY_POINT     SYS_C00128706     UNIQUE     2     4643     1447946     1     1     1442796     1447946
TEST ITEM 3     COMPARE PLANS
ENVIRONMENT A
Plan hash value: 4109575732
| Id | Operation                       | Name                   | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |                        |    13 | 2067 |       |   135K (2)| 00:27:05 |
|   1 | HASH UNIQUE                    |                        |    13 | 2067 |       |   135K (2)| 00:27:05 |
|* 2 |   HASH JOIN                     |                        |    13 | 2067 |       |   135K (2)| 00:27:05 |
|* 3 |    HASH JOIN                    |                        |     6 |   900 |       |   135K (2)| 00:27:04 |
|* 4 |     HASH JOIN ANTI              |                        |     1 |   137 |       |   135K (2)| 00:27:03 |
|* 5 |      TABLE ACCESS BY INDEX ROWID| NMI                    |     1 |    22 |       |     5   (0)| 00:00:01 |
|   6 |       NESTED LOOPS              |                        |     1 |   131 |       | 95137   (2)| 00:19:02 |
|* 7 |        HASH JOIN                |                        |     1 |   109 |       | 95132   (2)| 00:19:02 |
|* 8 |         TABLE ACCESS FULL       | ASSET                  | 36074 | 1021K|       | 38553   (2)| 00:07:43 |
|* 9 |         HASH JOIN               |                        | 90361 | 7059K| 4040K| 56578   (2)| 00:11:19 |
|* 10 |          HASH JOIN              |                        | 52977 | 3414K| 2248K| 50654   (2)| 00:10:08 |
|* 11 |           HASH JOIN             |                        | 39674 | 1782K|       | 40101   (2)| 00:08:02 |
|* 12 |            TABLE ACCESS FULL    | REGISTER               | 39439 | 1232K|       | 22584   (2)| 00:04:32 |
|* 13 |            TABLE ACCESS FULL    | SDP_LOGICAL_REGISTER   | 4206K|    56M|       | 17490   (2)| 00:03:30 |
|* 14 |           TABLE ACCESS FULL     | SERVICE_DELIVERY_POINT |   675K|    12M|       | 9412   (2)| 00:01:53 |
|* 15 |          TABLE ACCESS FULL      | SDP_LOGICAL_ASSET      | 1178K|    15M|       | 4262   (2)| 00:00:52 |
|* 16 |        INDEX RANGE SCAN         | IDX_NMI_ID_NK          |     2 |       |       |     2   (0)| 00:00:01 |
| 17 |      VIEW                       |                        | 39674 |   232K|       | 40101   (2)| 00:08:02 |
|* 18 |       HASH JOIN                 |                        | 39674 | 1046K|       | 40101   (2)| 00:08:02 |
|* 19 |        TABLE ACCESS FULL        | REGISTER               | 39439 |   500K|       | 22584   (2)| 00:04:32 |
|* 20 |        TABLE ACCESS FULL        | SDP_LOGICAL_REGISTER   | 4206K|    56M|       | 17490   (2)| 00:03:30 |
|* 21 |     TABLE ACCESS FULL           | METER_CONFIG_HEADER    | 3658 | 47554 |       |    19   (0)| 00:00:01 |
|* 22 |    TABLE ACCESS FULL            | METER_CONFIG_ITEM      | 7590 | 68310 |       |   112   (2)| 00:00:02 |
Predicate Information (identified by operation id):
   2 - access("METER_CONFIG_HEADER_SK"="METER_CONFIG_HEADER_SK")
   3 - access("NETWORK_TARIFF_CD"="NETWORK_TARIFF_CD")
   4 - access("SERVICE_DELIVERY_POINT_SK"="TMP"."SERVICE_DELIVERY_POINT_SK")
   5 - filter("ROW_CURRENT_IND"='Y' AND ("NMI_STATUS_CD"='A' OR "NMI_STATUS_CD"='D'))
   7 - access("ASSET_CD"="EQUIP_CD" AND "SAP_INT_LOG_DEVICE_SK"="SAP_INT_LOG_DEVICE_SK")
   8 - filter("ROW_CURRENT_IND"='Y')
   9 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK")
10 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK")
11 - access("SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")
12 - filter("REGISTER_TYPE_CD"='C' AND (SUBSTR("REGISTER_ID_CD",1,1)='4' OR
              SUBSTR("REGISTER_ID_CD",1,1)='5' OR SUBSTR("REGISTER_ID_CD",1,1)='6') AND "ROW_CURRENT_IND"='Y')
13 - filter("ROW_CURRENT_IND"='Y')
14 - filter("ROW_CURRENT_IND"='Y')
15 - filter("ROW_CURRENT_IND"='Y')
16 - access("NMI_SK"="NMI_SK")
18 - access("SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")
19 - filter("REGISTER_TYPE_CD"='C' AND (SUBSTR("REGISTER_ID_CD",1,1)='1' OR
              SUBSTR("REGISTER_ID_CD",1,1)='2' OR SUBSTR("REGISTER_ID_CD",1,1)='3') AND "ROW_CURRENT_IND"='Y')
20 - filter("ROW_CURRENT_IND"='Y')
21 - filter("ROW_CURRENT_IND"='Y')
22 - filter("ROW_CURRENT_IND"='Y' AND "CONROL_REGISTER"='X')
ENVIRONMENT B
Plan hash value: 2826260434
| Id | Operation                            | Name                   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                     |                        |     1 |   181 |   103K (2)| 00:20:47 |
|   1 | HASH UNIQUE                         |                        |     1 |   181 |   103K (2)| 00:20:47 |
|* 2 |   HASH JOIN ANTI                     |                        |     1 |   181 |   103K (2)| 00:20:47 |
|* 3 |    HASH JOIN                         |                        |     1 |   176 | 56855   (2)| 00:11:23 |
|* 4 |     HASH JOIN                        |                        |     1 |   163 | 36577   (2)| 00:07:19 |
|* 5 |      TABLE ACCESS BY INDEX ROWID     | ASSET                  |     1 |    44 |     4   (0)| 00:00:01 |
|   6 |       NESTED LOOPS                   |                        |     1 |   131 | 9834   (2)| 00:01:59 |
|   7 |        NESTED LOOPS                  |                        |     1 |    87 | 9830   (2)| 00:01:58 |
|   8 |         NESTED LOOPS                 |                        |     1 |    74 | 9825   (2)| 00:01:58 |
|* 9 |          HASH JOIN                   |                        |     1 |    52 | 9820   (2)| 00:01:58 |
|* 10 |           TABLE ACCESS BY INDEX ROWID| METER_CONFIG_HEADER    |     1 |    14 |     1   (0)| 00:00:01 |
| 11 |            NESTED LOOPS              |                        |     1 |    33 |   116   (2)| 00:00:02 |
|* 12 |             TABLE ACCESS FULL        | METER_CONFIG_ITEM      |     1 |    19 |   115   (2)| 00:00:02 |
|* 13 |             INDEX RANGE SCAN         | SYS_C00116570          |     1 |       |     1   (0)| 00:00:01 |
|* 14 |           TABLE ACCESS FULL          | SERVICE_DELIVERY_POINT |   723K|    13M| 9699   (2)| 00:01:57 |
|* 15 |          TABLE ACCESS BY INDEX ROWID | NMI                    |     1 |    22 |     5   (0)| 00:00:01 |
|* 16 |           INDEX RANGE SCAN           | IDX_NMI_ID_NK          |     2 |       |     2   (0)| 00:00:01 |
|* 17 |         TABLE ACCESS BY INDEX ROWID | SDP_LOGICAL_ASSET      |     1 |    13 |     5   (0)| 00:00:01 |
|* 18 |          INDEX RANGE SCAN            | IDX_SLA_SDP_SK         |     2 |       |     2   (0)| 00:00:01 |
|* 19 |        INDEX RANGE SCAN              | IDX_A_SAPINTLOGDEV_SK |     2 |       |     2   (0)| 00:00:01 |
|* 20 |      TABLE ACCESS FULL               | REGISTER               | 76113 | 2378K| 26743   (2)| 00:05:21 |
|* 21 |     TABLE ACCESS FULL                | SDP_LOGICAL_REGISTER   | 5095K|    63M| 20245   (2)| 00:04:03 |
| 22 |    VIEW                              |                        | 90889 |   443K| 47021   (2)| 00:09:25 |
|* 23 |     HASH JOIN                        |                        | 90889 | 2307K| 47021   (2)| 00:09:25 |
|* 24 |      TABLE ACCESS FULL               | REGISTER               | 76113 |   966K| 26743   (2)| 00:05:21 |
|* 25 |      TABLE ACCESS FULL               | SDP_LOGICAL_REGISTER   | 5095K|    63M| 20245   (2)| 00:04:03 |
Predicate Information (identified by operation id):
   2 - access("SERVICE_DELIVERY_POINT_SK"="TMP"."SERVICE_DELIVERY_POINT_SK")
   3 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK" AND
              "SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")
   4 - access("ASSET_CD"="EQUIP_CD")
   5 - filter("ROW_CURRENT_IND"='Y')
   9 - access("NETWORK_TARIFF_CD"="NETWORK_TARIFF_CD")
10 - filter("ROW_CURRENT_IND"='Y')
12 - filter("ROW_CURRENT_IND"='Y' AND "CONROL_REGISTER"='X')
13 - access("METER_CONFIG_HEADER_SK"="METER_CONFIG_HEADER_SK")
14 - filter("ROW_CURRENT_IND"='Y')
15 - filter("ROW_CURRENT_IND"='Y' AND ("NMI_STATUS_CD"='A' OR "NMI_STATUS_CD"='D'))
16 - access("NMI_SK"="NMI_SK")
17 - filter("ROW_CURRENT_IND"='Y')
18 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK")
19 - access("SAP_INT_LOG_DEVICE_SK"="SAP_INT_LOG_DEVICE_SK")
20 - filter((SUBSTR("REGISTER_ID_CD",1,1)='4' OR SUBSTR("REGISTER_ID_CD",1,1)='5' OR
              SUBSTR("REGISTER_ID_CD",1,1)='6') AND "REGISTER_TYPE_CD"='C' AND "ROW_CURRENT_IND"='Y')
21 - filter("ROW_CURRENT_IND"='Y')
23 - access("SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")
24 - filter((SUBSTR("REGISTER_ID_CD",1,1)='1' OR SUBSTR("REGISTER_ID_CD",1,1)='2' OR
              SUBSTR("REGISTER_ID_CD",1,1)='3') AND "REGISTER_TYPE_CD"='C' AND "ROW_CURRENT_IND"='Y')
25 - filter("ROW_CURRENT_IND"='Y')Edited by: abhilash173 on Feb 24, 2013 9:16 PM
Edited by: abhilash173 on Feb 24, 2013 9:18 PM

Hi Paul,
I misread your question initially .The system stats are outdated in both ( same result as seen from aux_stats) .I am not a DBA and do not have access to gather system stats fresh.
select * from sys.aux_stats$
SNAME     PNAME     PVAL1     PVAL2
SYSSTATS_INFO     STATUS     NULL     COMPLETED
SYSSTATS_INFO     DSTART     NULL     02-16-2011 15:24
SYSSTATS_INFO     DSTOP     NULL     02-16-2011 15:24
SYSSTATS_INFO     FLAGS     1     NULL
SYSSTATS_MAIN     CPUSPEEDNW     1321.20523     NULL
SYSSTATS_MAIN     IOSEEKTIM     10     NULL
SYSSTATS_MAIN     IOTFRSPEED     4096     NULL
SYSSTATS_MAIN     SREADTIM     NULL     NULL
SYSSTATS_MAIN     MREADTIM     NULL     NULL
SYSSTATS_MAIN     CPUSPEED     NULL     NULL
SYSSTATS_MAIN     MBRC     NULL     NULL
SYSSTATS_MAIN     MAXTHR     NULL     NULL
SYSSTATS_MAIN     SLAVETHR     NULL     NULL

Problem with temp space allocation in parallel query

Hello
I've got a query which matches two large result sets (25m+ rows) against each other and does some basic filtering and aggregation. When I run this query in serial it takes about 30 mins and completes successfully. When I specify a parallel degree of 4 for each result set, it also completes successfully in about 20 minutes. However, when I specify that it should be run in parallel but don't specify a degree for each result set, it spawns 10 parallel servers and after a couple of minutes, bombs out from one of the parallel servers with:
ORA-12801: error signaled in parallel query server P000
ORA-01652: unable to extend temp segment by 64 in tablespace TEMPThis appears to be when it is about to perform a large hash join. The execution plan does not change whether the parallel degree is specified or not, and there is several GB of temp space available.
I'm at a bit of a loss as to how to track down specifically what is causing this problem. I've looked at v$sesstat for all of the sessions involved and it hasn't really turned anything up. I've tried tracing the main session and that hasn't really turned up much either. From what I can tell, one of the sessions seems to try to allocate massive amounts of temp space that it just does not need, but I can figure out why.
Any ideas of how to approach finding the cause of the problem?
David

Hello
I've finally resolved this and the resolution was relatively simple - and was also the main thing that Mark Rittman said he did in his article: reduce the size of the hash join.
After querying v$sql_workarea_active I could see what was happening which was that the sum of the temp space for all of the parallel slaves was exceeding the total amount of temp space available on the system. When run in serial, it was virtually at the limit. I guess the extra was just the overhead for each slave maintaining it's own hash table.
I also made the mistake of misreading the exectuion plan - assuming that the data being pushed to the hash join was filtered to eliminate the data that was not of interest. Upon reflection, this was a rather stupid assumption on my part. Anyway, I used sub query factoring with the materialize hint to ensure that the hash join was only working on the data it should have been. This significantly reduced the size of the hash table and therefore the amount of temp space required.
I did speak to oracle support and they suggested using pga_aggregate_target rather than the separate *area_size parameters. I found that this had very little impact as the problem was related to the volume of data rather than whether it was being processed in memory or not. That said, I did try upping the hash_area_size for the session with some initial success, but ultimately it didn't prove to be scalable. We are however now using pga_aggregate_target in prod.
So that's that. Problem sorted. And as the title of Mark Rittman's article suggests, I was trying to be too clever! :-)
HTH
David

Parallel query in Oracle 11g

We use Oracle 11g DB on windows2008R2.
We wrote very long and heavy SELECT SQL query usign several table join and sub-queries and it take very long time to get result.
We did SQL statement tuning as much as we can do so far. ( I will get the Execution Plan and ADDM, etc access right)
I today notice about Parallel query function.
Where could I write parallel hint phrases in very long SELECT SQL query ?
In each selected tables like below ?
/sample in Oracle Doc/
SELECT /*+ PARALLEL(employees 4) PARALLEL(departments 4)
USE_HASH(employees) ORDERED */ MAX(salary), AVG(salary)
FROM employees, departments
WHERE employees.department_id = departments.department_id
GROUP BY employees.department_id;

You need to be careful with some of the examples in the docs. The example you quote includes an unnecessary join. Before considering parallel query, it should have been re-written to this:
SELECT MAX(salary), AVG(salary)
FROM employees
WHERE department_id is not null
GROUP BYdepartment_id;
Later versions of the CBO may do this re-write for you, but it is important to understand why the SQL is inefficient before throwing parallel servers at it. Are you sure that all your joins are actually necessary? (I know you are just going to say "yes", but you might want to think about it first.)

Parallel query problem

problem:
In this explain plan 3 indexes are used and I altered these indexes with no parallel degree 1. after that its again using the parallel query...
How to disable the parallel query use for the mentioned above....
Plz help me out....
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 54 | 3 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10001 | 1 | 54 | 3 | | | Q1,01 | P->S | QC (RAND) |
| 3 | NESTED LOOPS | | 1 | 54 | 3 | | | Q1,01 | PCWP | |
| 4 | NESTED LOOPS ANTI | | 1 | 42 | 3 | | | Q1,01 | PCWP | |
| 5 | NESTED LOOPS | | 1 | 28 | 3 | | | Q1,01 | PCWP | |
| 6 | BUFFER SORT | | | | | | | Q1,01 | PCWC | |
| 7 | PX RECEIVE | | | | | | | Q1,01 | PCWP | |
| 8 | PX SEND BROADCAST | :TQ10000 | | | | | | | S->P | BROADCAST |
| 9 | TABLE ACCESS BY GLOBAL INDEX ROWID| LEA_AGREEMENT_DTL | 1 | 10 | 1 | 1 | 1 | | | |
| 10 | INDEX UNIQUE SCAN | LEA_AGREEMENT_DTL_UQ | 1 | | 1 | | | | | |
| 11 | PX BLOCK ITERATOR | | 1 | 18 | 2 | | | Q1,01 | PCWC | |
| 12 | TABLE ACCESS FULL | PDC_DISBURSAL_TXN_D | 1 | 18 | 2 | | | Q1,01 | PCWP | |
| 13 | INDEX RANGE SCAN | PDC_MULTIPLE_LOAN_TXN_DE | 1 | 14 | 1 | | | Q1,01 | PCWP | |
| 14 | TABLE ACCESS BY INDEX ROWID | PDC_DISBURSAL_TXN_H | 1 | 12 | 1 | | | Q1,01 | PCWP | |
| 15 | INDEX UNIQUE SCAN | PDC_DISBURSAL_TXN_H_PK_01 | 1 | | 1 | | | Q1,01 | PCWP | |
-----------------------------------------------------------------------------------------------------------------------------------------------------_

please try to use "noparallel hints" in your query.
R.Wang
http://www.oraclepoint.com

Apply process is aborting with:ORA-12801: error signaled in parallel query

hi,
We created a queue of a specific type, capture and apply process on the queue. Then we started the queue capture and the apply process. The problem is that the apply process is getting enabled and with in moments going into aborted state. wea re getting the follwoing error:
ORA-12801: error signaled in parallel query server P000
ORA-00600: internal error code, arguments: [kwqiceval:anyconv], [], [], [], [], [], [], []
Any idea what could have gone wrong?
scripts:
exec dbms_aqadm.create_queue_table(queue_table=>'qt_anc',queue_payload_type=>'type_anc',multiple_consumers=> true, compatible => '9.0');
exec dbms_aqadm.create_queue (queue_name => 'q_anc',queue_table=>'qt_anc');
EXEC DBMS_AQADM.START_QUEUE (queue_name => 'q_anc');
DECLARE
emp_rule_name_dml VARCHAR2(300);
emp_rule_name_ddl VARCHAR2(300);
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'ops.t_anc',
streams_type => 'capture',
streams_name => 'capture_anc',
queue_name => 'strmadmin.q_anc',
include_dml => true,
include_ddl => false,
source_database => null,
dml_rule_name => emp_rule_name_dml,
ddl_rule_name => emp_rule_name_ddl);
DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATION(
rule_name => emp_rule_name_dml,
destination_queue_name => 'strmadmin.q_anc');
END;
DECLARE
emp_rule_name_dml VARCHAR2(300);
emp_rule_name_ddl VARCHAR2(300);
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'ops.t_anc',
streams_type => 'apply',
streams_name => 'apply_anc',
queue_name => 'strmadmin.q_anc',
include_dml => true,
include_ddl => false,
source_database => null,
dml_rule_name => emp_rule_name_dml,
ddl_rule_name => emp_rule_name_ddl);
DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATION(
rule_name => emp_rule_name_dml,
destination_queue_name => 'strmadmin.q_anc');
END;
BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name => 'apply_anc');
END;
BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name => 'capture_anc');
END;
/

Hello
The above configuration is never supported. The implicit capture expects the queue payload to be SYS.ANYDATA and same with implicit apply also.
However you can use Streams Messaging capability to achieve this. You need to wrap the messages with SYS.ANYDATA for this to work. The implicit capture uses a persistent logminer session to generate LCRs and it then wraps it with SYS.ANYDATA and enqueues into the capture queue, it then propagated to apply queue. You can generate LCRs and wrap it with SYS.ANYDATA and then enqueue into the capture queue then apply can recognise the messages.
Here is an example on creating LCRs (tested in 10g):
CREATE TABLE lcr_test (col1 NUMBER);
DECLARE
     l_lcr SYS.LCR$_ROW_RECORD;
BEGIN
     l_lcr :=
SYS.LCR$_ROW_RECORD.CONSTRUCT
     source_database_name=>SYS_CONTEXT('USERENV','DB_NAME'),
     command_type=>'INSERT',
     object_owner=>USER,
     object_name=>'LCR_TEST'
     l_lcr.ADD_COLUMN('new','col1',SYS.AnyData.ConvertNumber(99));
     l_lcr.EXECUTE(TRUE);
     COMMIT;
END;
SELECT * FROM lcr_test;
Converting to SYS.ANYDATA:
DECLARE
     l_lcr SYS.LCR$_ROW_RECORD;
     l_anydata SYS.ANYDATA;
BEGIN
     l_lcr :=
SYS.LCR$_ROW_RECORD.CONSTRUCT
     source_database_name=>SYS_CONTEXT('USERENV','DB_NAME'),
     command_type=>'INSERT',
     object_owner=>USER,
     object_name=>'LCR_TEST'
     l_lcr.ADD_COLUMN('new','col1',SYS.AnyData.ConvertNumber(99));
     l_anydata:=SYS.ANYDATA.ConvertObject(l_lcr);
     ENQ_PROC(l_anydata);
     COMMIT;
END;
Thanks,
Rijesh

Oracle11g RAC with partitioning and cross instance parallel query problem

I have set up a 300gb TPC-H database using a 4 node RAC environment (8 cpu per node, 16 GB memory, 2 GHz processors) the system is served by 2.5 terabytes of SSD for its IO subsystem managed by a combination of ASM and OCFS2.
When I run a large parallel query (number 9 in the TPCH query set) I get:
ORA-00600: internal error code, arguments [kxfrGraDistNum3],[65535],[4]
with all other arguments blank. There were some reports of this in version 9, but it was supposedly fixed. Has any one seen this behavior or have a work around?
Mike

Good Idea! Why didn't I think of that? Oh yea...I did. Unfortunately TMS CSI is an update only partner type CSI so I cannot submit a SR. The 600 lookup was how I found the old stuff, but it didn't have any 11g references. I hoped maybe someone in the community had encountered this and had a workaround. By the way, the querey looks like so:
select
nation,
o_year,
sum(amount) as sum_profit
from
select
n_name as nation,
extract(year from o_orderdate) as o_year,
l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount
from
h_part,
h_supplier,
h_lineitem,
h_partsupp,
h_order,
h_nation
where
s_suppkey = l_suppkey
and ps_suppkey = l_suppkey
and ps_partkey = l_partkey
and p_partkey = l_partkey
and o_orderkey = l_orderkey
and s_nationkey = n_nationkey
and p_name like '%spring%'
) as profit
group by
nation,
o_year
order by
nation,
o_year desc;
the other 21 queries, all using the same tables and degrees of paralell and cross instance settings, executed ok.
Mike

Parallel Query Error (Ora 12801 Ora-00904)

when i run this particular query in a report or in SQL it wrks
but some times it give the error .........
any one who could help ........ASAP
SELECT
D.DISTRIBUTOR_CODE "DIST_CODE",
D.DISTRIBUTOR_NAME "DIST_NAME",
O.OPERATOR_CODE "OPER_CODE",
O.OPERATOR_NAME "OPER_NAME",
O.ACTIVE_STATUS "Act",
r.receipt_no "receipt_no",
r.ch_or_dd_no "cheque",
r.receipt_date "receipt_date",
'' "channel Code",
'' "channel_name",
b. SUBS_IRD "ird_subs",
b.amount "amount"
FROM
dms_channel_dump z,
DMS_OPERATOR_MASTER O,
DMS_DISTRIBUTOR_MAIN D,
dms_receipt_header r,
DMS_BIFURCATION b
WHERE
b.channel_code = z.channel_code
and r.OPERATOR_CODE = O.OPERATOR_CODE
AND r.DISTRIBUTOR_CODE = D.DISTRIBUTOR_CODE
AND r.receipt_no = b.receiopt_no
union all
SELECT
D.DISTRIBUTOR_CODE "DIST_CODE",
D.DISTRIBUTOR_NAME "DIST_NAME",
'' "OPER_CODE",
'' "OPER_NAME",
'N' "Act",
r.receipt_no "receipt_no",
r.ch_or_dd_no "cheque",
r.receipt_date "receipt_date",
b.channel_code "channel Code",
z.channel_name "channel_name",
b. SUBS_IRD "ird_subs",
b.amount "amount"
FROM
dms_channel_dump z,
DMS_OPERATOR_MASTER O,
DMS_DISTRIBUTOR_MAIN D,
dms_receipt_header r,
DMS_BIFURCATION b
WHERE
b.channel_code = z.channel_code
and r.OPERATOR_CODE is null
AND r.DISTRIBUTOR_CODE = D.DISTRIBUTOR_CODE
AND r.receipt_no = b.receiopt_no
order by 4,7
ERROR:
ORA-12801: error signaled in parallel query server P004
ORA-00904: invalid column name
no rows selecte
REGARDS AND TIA
ADOLPH

If the data never changes, there would be no reason to gather statistics.
If the data changes, there may or may not be a reason to gather statistics. There is some risk to gathering statistics because that can cause query plans to change and you could find that a query that was working fine yesterday is running very slowly today. Failing to gather statistics, though, can have the same effect-- if a histogram on a column indicates that the maximum value of a date field is December 1, 2006 because you haven't updated statistics in a few days, the CBO may conclude that a query this column with a value of December 4 would return very few row, rather than the many rows that are really there, causing Oracle to use a different query plan. Oracle tends to believe that the latter risk is more of a concern than the former and in 10g regularly and automatically gathers statistics unless you susped that job. Some DBAs disagree with Oracle and prefer less frequent, more controlled statistics gathering.
If you GATHER AUTO, assuming your tables are set to MONITORING, Oracle gathers statistics on every table that has had more than some cutoff percentage of rows changed since statistics were last gathered. This cutoff is generally pretty reasonable, though ideally you'd probably want to gather statistics more frequently on smaller tables (adding 30 new rows to a 100 row table is probably more significant from a query plan perspective than adding 3 million rows to a 10 million row table) and less frequently on larger tables, more frequently on tables that have volatile data distributions (i.e. our DATE table) and less frequently on tables whose data distribution is relatively constant.
Justin

Parallel execution without table name

Hello,
i.e.
select /*+ parallel */ a.abc, b.xyz
from apple a, baby b;
It is not necessary to specify a table name for parallelism or degree of parallelism (DOP); however,
what is the degree of parallelism for each table if DOP is not specified?
Thanks.

Hi,
default DOP for table is 1. you can check with the Query dba_tables/user_tables with the help of column DEGREE

ORA-12827 insufficient parallel query slaves available

Hi,
In our sql statements , we are using PARALLEL_MIN_PERCENT = 100 for getting 100% parallel slaves.
But sometimes,it fails with ORA-12827.
if we remove PARALLEL_MIN_PERCENT = 100 , then obviously the query execution time will increase.
How to make sure that the query always get 100% parallel query slaves?
Is there any work around for this other than removing or changing PARALLEL_MIN_PERCENT?
Thanks

Increase parallel_min_servers. What happens is as follows. At instance startup oracle starts parallel_min_servers processes to handle PQO (Parallel Query Option). Assume, for example parallel_min_servers = 4. Assume table has degree of parallelism 6. When you set PARALLEL_MIN_PERCENT = 100 you are requesting PQO to start 6 slave processes while only 4 are available.
SY.

Parallel Query Restirction

Hi there,
i was wondering if there is any option to restrict the parallel execution of queries for user, so if a specific user exceutes select /*+ parallel*/ from table
i want the query to be executed as noparallel??
thank you in advance.
My Oracle Version is:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
"CORE 11.1.0.7.0 Production"
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

1) You can put suspicious users in certain Resource Consumer Groups and limit the Parallel Degree of that group to 1 (no parallelism).
2) If the parallel query is obviously not appropriate, you may also implement Automatic DOP to prevent senseless parallelism.
See here for an example for 2):
http://uhesse.wordpress.com/2009/11/24/automatic-dop-in-11gr2/
Kind regards
Uwe Hesse
http://uhesse.wordpress.com
Edited by: Uwe Hesse on 13.07.2011 20:22
corrected -> certain

Parallel querying ignored.

Guys,
I've a table at a remote database instance,which I query from my instance shows the usage of Parallel querying
SQL> EXPLAIN PLAN FOR
2 select f.* from fact@orcl f;
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
| Id | Operation              | Name                 | Rows | Bytes | Cost (%CPU)| TQ    |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT REMOTE|                       |   908K|   279M| 1881   (2)|        |      |            |
|   1 | PX COORDINATOR        |                       |       |       |            |        |      |            |
|   2 |   PX SEND QC (RANDOM) | :TQ10000              |   908K|   279M| 1881   (2)| Q1,00 | P->S | QC (RAND) |
|   3 |    PX BLOCK ITERATOR   |                       |   908K|   279M| 1881   (2)| Q1,00 | PCWC |            |
|   4 |     TABLE ACCESS FULL | FACT                  |   908K|   279M| 1881   (2)| Q1,00 | PCWP |            |
------------------------------------------------------------------------------------------------------------------However if I join the table with my local table,parallel querying doesn't happen anymore.
SQL> EXPLAIN PLAN FOR
2 select f.* from fact@orcl f,time_perd t
3 WHERE f.id=t.id;
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
| Id | Operation             | Name               | Rows | Bytes | Cost (%CPU)| Inst   |IN-OUT|
|   0 | SELECT STATEMENT      |                     |     1 |   329 | 14014 (53)|        |      |
|* 1 | HASH JOIN            |                     |     1 |   329 | 14014 (53)|        |      |
|   2 |   INDEX FAST FULL SCAN| TIME_PERD_PK        | 16398 | 98388 |    18 (62)|        |      |
|   3 |   REMOTE              |                     |   908K|   279M|            | ORCL   | R->S |
--------------------------------------------------------------------------------------------------Could some explain the reason why.I tried adding parallel hint to the query,but its the same execution plan that I get.
Thanks,
Bhagat

I beleive I would've better luck re-opening my ealier question and hope to get a solution.
I've a table at my local instance with degree of parallelism '4'
I've another table at remote instance with degree of parallelism '4'
Select on local table does get executed in parallel.(From the Execution plan)
Select on remote table from my local instance(table@db_link) does get executed in parallel.(From the Execution plan)
However
Select of a query joining both tables doesn't show parallel execution.
Now, what hint would be appropriate for the above query to be executed in parallel?
Let me know if anyone have ideas.
Thanks you!!!!!
Regards,
Bhagat

Set table level degree for partitioned table

Hi all,
Usually, we set degree 2 or 4 to big tables. In this case, CBO will choose parallel select for these tables if possible.
Let assume one case that is table1 joins table2. non-partitioned Table1 has 20m rows and has degree 2. partitioned table2 has 50m rows and has no parallel degree.
When I checked the execution plan, CBO uses parallel execution and uses PX BLOCK ITERATOR on table1 as expected. But I don't know whether table2 is selected in parallel, too.
I mean I am not sure whether CBO launches slave processes against table2 or just select table2 as a whole.
And with your tuning or architecture experiences, do you think whehther we should set degree for a partitioned table as the partitioned table can be parallelized based on partitions?
best regards,
Leon

user12064076 wrote:
And with your tuning or architecture experiences, do you think whether we should set degree for a partitioned table as the partitioned table can be parallelized based on partitions?What version of Oracle?
A site I worked at recently preferred not to hard-code the degree but to let Oracle choose it at runtime; they felt it offered better allocation of system load than hard-coding the values. They were on 10g release 2.

CBO generating Parallel Query on tables of Degree 1

Similar Messages

Maybe you are looking for