Session of parallel query of murder

Hello
I'm under Oracle 11.2.0.1.0 on Solaris 5.10.

A few hours ago, I ran a job through DBMS_JOB (Yes, I need to use dbms_schedular), and in the work, I used a parallel query. Now, I want to delete the task. I would also like to clean up the sessions. I can remove the work by DBMS_JOB.remove (identification). Is it possible that I have killed a parallel query session Coordinator and he would automatically kill all sessions of the slave?

Thanks and greetings

Published by: Fahd Mirza on April 22, 2010 11:57

Very simple, run

Select "Co-ordinator of the query" qcsid, count (*) as 'Slaves Count' of the Group v$ px_session by qcsid;

kill the request coordinators and all his servants will be killed too.

Tags: Database

Similar Questions

Please help with parallel query
Hi all

I am "playing" with a parallel query and try to see if it could improve some more long running queries, but can't do the database that you want to use a parallel execution plan, no matter what I do! I hope someone can point me in the right direction!

ORACLE Version is 11.2.0.2
OS Win 2008 R2 server
UC = 32
64 GB OF RAM
AMM enabled, memory_target = M 50560

SQL > show the parallel parameter

VALUE OF TYPE NAME
------------------------------------ ----------- --------------
fast_start_parallel_rollback string LOW
parallel_adaptive_multi_user Boolean TRUE
parallel_automatic_tuning boolean FALSE
parallel_degree_limit string CPU
parallel_degree_policy string AUTO
parallel_execution_message_size integer 16384
parallel_force_local boolean FALSE
parallel_instance_group string
parallel_io_cap_enabled boolean FALSE
PARALLEL_MAX_SERVERS integer 985
parallel_min_percent integer 0

VALUE OF TYPE NAME
------------------------------------ ----------- --------------
parallel_min_servers integer 16
parallel_min_time_threshold channel 5
parallel_server boolean FALSE
parallel_server_instances integer 1
parallel_servers_target integer 512
parallel_threads_per_cpu integer 2
recovery_parallelism integer 0
I also ran the calibration of IO which resultet

Max e/s per second 21569
Max Mo / second 989
I collected statistics of the system, the 1 hour time. the results are:

Select pname, sys.aux_stats pval1 $;
STATUS
DSTART
DSTOP
FLAGS 0
CPUSPEEDNW 915
IOSEEKTIM 10
IOTFRSPEED 4096
SREADTIM 0.589
MREADTIM 0.841
CPUSPEED 1355
MBRC 11
MAXTHR 679936
SLAVETHR
I changed all my tables and indexes using 'ALTER TABLE xxx PARALLEL' then when I query the dba_tables, the DEGREE is DEFAULT for all objects invoked in my queries.

what I've learned so far, I put all the necessary parameters.
From my understanding, all queries who believe more than 5 seconds, should be tried to run in parallel (parallel_min_time_threshold = 5). But not a single query is doing at least this forced manually with a / * + PARALLEL * / tip! It drives me crazy. Choose manually a degree of 16 for example allows to speed up some queries from 15 minutes to 1 minute, but why ORACLE does not by itself?
Given that it is a Siebel application, that we are talking about, there is no possibility of adding tips for SQL.

example:

This query took 29 seconds to complete, but was executed in SERIES

SQL_ID, atzj0dmhshb23, number of children 0
-------------------------------------
SELECT T7. CONFLICT_ID, T7. LAST_UPD, T7. CREATED,
T7. LAST_UPD_BY, T7. CREATED_BY, T7. MODIFICATION_NUM,
T7. ROW_ID, T9. MAIN_PH_NUM, T9.NAME, T9. REGION,
T9. X_SUB_REGION, T20. ATTRIB_44, T20. ATTRIB_26,
T20. ATTRIB_45, T20. ATTRIB_27, T20. ATTRIB_03,
T33. SUPPRESS_MAIL_FLG, T33. EMAIL_ADDR, T33. MID_NAME,
T33. PR_DEPT_OU_ID, T33. LAST_NAME, T33. SEX_MF,
T33. PR_PER_ADDR_ID, T33. PR_POSTN_ID, T30. PR_ADDR_ID,
T33. HOME_PH_NUM, T33. OWNER_PER_ID, T33. WORK_PH_NUM,
T33. FAX_PH_NUM, T33. FST_NAME, T20. ATTRIB_07,
T3. INTEGRATION_ID, T33. PR_PER_PAY_PRFL_ID, T33. PRIV_FLG,
T33. PR_MKT_SEG_ID, T33. PR_REP_SYS_FLG,
T33. PR_REP_MANL_FLG, T33. PR_REP_DNRM_FLG, T33. PR_OPTY_ID,
T33. PR_GRP_OU_ID, T33. EMP_FLG, T8. OWN_INST_ID,
T8. INTEGRATION_ID, T33. PERSON_UID, T7. NAM

Hash value of plan: 35208051

---------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
---------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 34 (100) |
| 1. NESTED EXTERNAL LOOPS | 10. 42440 | 34 (0) | 00:00:01 |
| 2. NESTED EXTERNAL LOOPS | 10. 42300 | 33 (0) | 00:00:01 |
| 3. NESTED EXTERNAL LOOPS | 10. 42160 | 32 (0) | 00:00:01 |
| 4. NESTED EXTERNAL LOOPS | 10. 42020 | 31 (0) | 00:00:01 |
| 5. NESTED LOOPS | 10. 41880 | 30 (0) | 00:00:01 |
| 6. NESTED EXTERNAL LOOPS | 11. 45947 | 29 (0) | 00:00:01 |

| 7. NESTED LOOPS | 11. 45716 | 28 (0) | 00:00:01 |
| 8. NESTED EXTERNAL LOOPS | 11. 45364 | 27 (0) | 00:00:01 |
| 9. NESTED EXTERNAL LOOPS | 11. 45243 | 26 (0) | 00:00:01 |
| 10. NESTED EXTERNAL LOOPS | 11. 45122 | 25 (0) | 00:00:01 |
| 11. NESTED EXTERNAL LOOPS | 11. 43648 | 24 (0) | 00:00:01 |
| 12. NESTED EXTERNAL LOOPS | 11. 37070 | 23 (0) | 00:00:01 |
| 13. NESTED EXTERNAL LOOPS | 11. 34661 | 22 (0) | 00:00:01 |
| 14. NESTED EXTERNAL LOOPS | 11. 34430 | 21 (0) | 00:00:01 |
| 15. NESTED EXTERNAL LOOPS | 11. 33891 | 20 (0) | 00:00:01 |
| 16. NESTED EXTERNAL LOOPS | 11. 33253 | 19 (0) | 00:00:01 |
| 17. NESTED EXTERNAL LOOPS | 11. 32362 | 18 (0) | 00:00:01 |
| 18. NESTED EXTERNAL LOOPS | 11. 31999 | 17 (0) | 00:00:01 |
| 19. NESTED EXTERNAL LOOPS | 11. 29337 | 16 (0) | 00:00:01 |
| 20. NESTED EXTERNAL LOOPS | 11. 28556 | 15 (0) | 00:00:01 |
| 21. NESTED EXTERNAL LOOPS | 11. 28061 | 14 (0) | 00:00:01 |
| 22. NESTED EXTERNAL LOOPS | 11. 26400 | 13 (0) | 00:00:01 |
| 23. NESTED EXTERNAL LOOPS | 11. 26169 | 12 (0) | 00:00:01 |
| 24. NESTED EXTERNAL LOOPS | 11. 25465 | 10 (0) | 00:00:01 |
| 25. NESTED EXTERNAL LOOPS | 11. 21131. 9 (0) | 00:00:01 |
| 26. NESTED EXTERNAL LOOPS | 11. 18326. 8 (0) | 00:00:01 |
| 27. NESTED LOOPS | 11. 13651 | 7 (0) | 00:00:01 |
| 28. NESTED EXTERNAL LOOPS | 11. 12452. 6 (0). 00:00:01 |
| 29. NESTED EXTERNAL LOOPS | 11. 10978. 5 (0) | 00:00:01 |
| 30. NESTED LOOPS | 11. 9504. 4 (0) | 00:00:01 |
| 31. NESTED EXTERNAL LOOPS | 4. 360 | 3 (0) | 00:00:01 |
| 32. NESTED LOOPS | 4. 228. 2 (0) | 00:00:01 |
| * 33 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1. 11. 1 (0) | 00:00:01 |
| 34. TABLE ACCESS BY INDEX ROWID | S_CONTACT_BU | 4. 184. 1 (0) | 00:00:01 |
| * 35 | INDEX RANGE SCAN | S_CONTACT_BU_M1 | 4 | | 1 (0) | 00:00:01 |
| 36. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1. 33. 1 (0) | 00:00:01 |
| * 37 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0) | 00:00:01 |
| * 38 | TABLE ACCESS BY INDEX ROWID | S_CONTACT. 3. 2322 | 1 (0) | 00:00:01 |
| * 39 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0) | 00:00:01 |
| 40. TABLE ACCESS BY INDEX ROWID | S_MED_SPEC | 1. 134. 1 (0) | 00:00:01 |
| * 41. INDEX UNIQUE SCAN | S_MED_SPEC_P1 | 1 | | 1 (0) | 00:00:01 |
| 42. TABLE ACCESS BY INDEX ROWID | S_PRI_LST | 1. 134. 1 (0) | 00:00:01 |
| * 43. INDEX UNIQUE SCAN | S_PRI_LST_P1 | 1 | | 1 (0) | 00:00:01 |
| * 44 | TABLE ACCESS BY INDEX ROWID | S_PARTY | 1. 109. 1 (0) | 00:00:01 |
| * 45 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | | 1 (0) | 00:00:01 |
| 46. TABLE ACCESS BY INDEX ROWID | S_CONTACT_SS | 1. 425. 1 (0) | 00:00:01 |
| * 47 | INDEX RANGE SCAN | S_CONTACT_SS_U1 | 1 | | 1 (0) | 00:00:01 |
| 48. TABLE ACCESS BY INDEX ROWID | S_CONTACT_LOYX | 1. 255. 1 (0) | 00:00:01 |
| * 49 | INDEX RANGE SCAN | S_CONTACT_LOYX_U1 | 1 | | 1 (0) | 00:00:01 |
| * 50 | INDEX RANGE SCAN | S_DQ_CON_KEY_U1 | 1. 394. 1 (0) | 00:00:01 |
| * 51 | TABLE ACCESS FULL | S_CASE | 1. 64. 0 (0) |
| 52. TABLE ACCESS BY INDEX ROWID | S_POSTN | 1. 21. 1 (0) | 00:00:01 |
| * 53 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | 1 (0) | 00:00:01 |
| 54. TABLE ACCESS BY INDEX ROWID | S_EMP_PER | 1. 151. 1 (0) | 00:00:01 |
| * 55 | INDEX UNIQUE SCAN | S_EMP_PER_U1 | 1 | | 1 (0) | 00:00:01 |
| 56. TABLE ACCESS BY INDEX ROWID | S_POSTN_CON | 1. 45. 1 (0) | 00:00:01 |
| * 57 | INDEX RANGE SCAN | S_POSTN_CON_M3 | 4 | | 1 (0) | 00:00:01 |
| 58. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_FNX | 1. 71. 1 (0) | 00:00:01 |
| * 59 | INDEX RANGE SCAN | S_ORG_EXT_FNX_U1 | 1 | | 1 (0) | 00:00:01 |
| 60. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 1. 242. 1 (0) | 00:00:01 |
| * 61. INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 1 | | 1 (0) | 00:00:01 |
| 62. TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 1. 33. 1 (0) | 00:00:01 |
| * 63. INDEX RANGE SCAN | S_CON_ADDR_M51 | 1 | | 1 (0) | 00:00:01 |
| 64. TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1. 51 M | 1 (0) | 00:00:01 |
| * 65 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | 1 (0) | 00:00:01 |
| 66. TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1. 58. 1 (0) | 00:00:01 |
| * 67. INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | 1 (0) | 00:00:01 |
| 68. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1. 49. 1 (0) | 00:00:01 |
| * 69 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0) | 00:00:01 |
| 70. TABLE ACCESS BY INDEX ROWID | S_POSTN | 1. 21. 1 (0) | 00:00:01 |
| * 71 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | 1 (0) | 00:00:01 |
| 72. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1. 219. 1 (0) | 00:00:01 |
| * 73 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0) | 00:00:01 |
| 74. TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1. 598. 1 (0) | 00:00:01 |
| * 75 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0) | 00:00:01 |
| 76. TABLE ACCESS BY INDEX ROWID | S_CONTACT_X | 1. 134. 1 (0) | 00:00:01 |
| * 77 | INDEX RANGE SCAN | S_CONTACT_X_U1 | 1 | | 1 (0) | 00:00:01 |
| * 78 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1. 11. 1 (0) | 00:00:01 |
| * 79 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1. 11. 1 (0) | 00:00:01 |
| 50 M | TABLE ACCESS BY INDEX ROWID | S_POSTN_CON | 1. 32. 1 (0) | 00:00:01 |
| * 81 | INDEX RANGE SCAN | S_POSTN_CON_M3 | 1 | | 1 (0) | 00:00:01 |
| 82. TABLE ACCESS BY INDEX ROWID | S_POSTN | 1. 21. 1 (0) | 00:00:01 |
| * 83 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | 1 (0) | 00:00:01 |
| * 84 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1. 11. 1 (0) | 00:00:01 |
| 85. TABLE ACCESS BY INDEX ROWID | S_USER | 1. 14. 1 (0) | 00:00:01 |
| * 86 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0) | 00:00:01 |
| 87. TABLE ACCESS BY INDEX ROWID | S_USER | 1. 14. 1 (0) | 00:00:01 |
| * 88. INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0) | 00:00:01 |
| 89. TABLE ACCESS BY INDEX ROWID | S_USER | 1. 14. 1 (0) | 00:00:01 |
| * 90 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0) | 00:00:01 |
| 91. TABLE ACCESS BY INDEX ROWID | S_USER | 1. 14. 1 (0) | 00:00:01 |
| * 92 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0) | 00:00:01 |
---------------------------------------------------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):
---------------------------------------------------

33 - access("T15".") ROW_ID "(=:2)"
35 - access("T1".") BU_ID "(=:2)"
37 - access("T2".") PAR_ROW_ID "(=:2)"
38 - filter ((NLS_UPPER ("LAST_NAME", '= "GENERIC_BASELETTER" nls_sort') AS
NLS_UPPER(:3,'nls_sort=''GENERIC_BASELETTER''') AND 'T33 '. "PRIV_FLG"(='N')) "
39 - access("T33".") ROW_ID '= 'T1'.' CONTACT_ID')
41 - access("T33".") MED_SPEC_ID '= 'T5'.' ROW_ID")
43 - access("T33".") CURR_PRI_LST_ID "="T18"." ROW_ID")
44 - filter("T7".") PARTY_TYPE_CD' <>'Suspect')
45 - access("T7".") ROW_ID "= 'T33'." PAR_ROW_ID')
47 - access("T7".") ROW_ID "="T8"." PAR_ROW_ID')
49 - access("T7".") ROW_ID "="T12"." PAR_ROW_ID')
50 - access("T7".") ROW_ID "="T19"." CONTACT_ID')
51 - filter("T7".") ROW_ID "= 'T25'." PR_SUBJECT_ID')
53 - access("T33".") PR_POSTN_ID "="T21"." PAR_ROW_ID')
55 - access("T7".") ROW_ID "="T23"." PAR_ROW_ID')
57 - access("T30".") POSTN_ID ' =: 1 AND "T7".» ROW_ID "= 'T30'." CON_ID')
59 - access("T33".") PR_DEPT_OU_ID '= 'T22'.' PAR_ROW_ID')
61 - access("T33".") PR_DEPT_OU_ID "="T14"." PAR_ROW_ID')
63 - access("T33".") PR_OU_ADDR_ID '= 'T11'.' ADDR_PER_ID' AND 'T33 '. "PR_DEPT_OU_ID"= "T11". ("' ACCNT_ID")
65 - access("T33".") PR_PER_ADDR_ID "="T32"." ROW_ID")
67 - access("T33".") PR_OU_ADDR_ID "="T17"." ROW_ID")
69 - access("T33".") PR_DEPT_OU_ID '= 'T3'.' PAR_ROW_ID')
71 - access("T3".") PR_POSTN_ID '= 'T31'.' PAR_ROW_ID')
73 - access("T33".") PR_DEPT_OU_ID "="T9"." PAR_ROW_ID')
75 - access("T33".") PR_DEPT_OU_ID '= 'T13'.' PAR_ROW_ID')
77 - access("T7".") ROW_ID "="T20"." PAR_ROW_ID')
78 - access("T33".") PR_DEPT_OU_ID '= 'T4'.' ROW_ID")
79 - access("T33".") PR_SYNC_USER_ID '= 'T16'.' ROW_ID")
81 - access("T33".") PR_POSTN_ID '= 'T29'.' POSTN_ID' AND 'T33 '. "ROW_ID"= 'T29'. ("' CON_ID")
83 - access("T29".") POSTN_ID "="T6"." PAR_ROW_ID')
84 - access("T29".") POSTN_ID "= 'T27'." ROW_ID")
86 - access("T6".") PR_EMP_ID "="T26"." PAR_ROW_ID')
88 - access("T21".") PR_EMP_ID '= 'T28'.' PAR_ROW_ID')
90 - access("T31".") PR_EMP_ID '= 'T24'.' PAR_ROW_ID')
92 - access("T33".") PR_SYNC_USER_ID '= 'T10'.' PAR_ROW_ID')

Note
-----
-dynamic sample used for this survey (level = 5)
-Automatic DOP: calculated degree of parallelism is 1 because of the parallel threshold
-Profile SQL SYS_SQLPROF_013b617a8f0b005f used for this statement
Looks like ORACLE considers all my questions with '1 second' which is the parallel threshold (5 seconds) and so works in series? Or am I completely wrong?

(continued)

Edited by: Penky 5 December 2012 09:37
Penky wrote:
Randolf,

db_file_multiblock_read_count find not at all as far as I know, so it translates the default of 128 to 11 g. I read somewhere that it's not recommended to set it manually 10 or 11 and following.

Thank you for the values. Which is recommended, fix, but still a lot together sites of value to something by default. I don't know yet where this MB_IO_COUNT = 8 comes, however.

Furthermore, if you do want to play with the DOP Auto, you could just stick to the old manual DOP. If you set your PARALLEL_DEGREE_POLICY MANUAL, but have the objects marked as PARALLEL, you should get a PARALLEL query, it has provided is no less available to the optimizer serial plan.

The default DOP is very susceptible to high (64 per node with your given configuration), you can set the PARALLEL degree to something lower.

You could also play with ALTER SESSION FORCE PARALLEL QUERY PARALLEL x if you want / can limit this to specific sessions, then you have even to mark objects as PARALLEL, such that it could have side effects to other processes that you do not want to run in parallel.

Randolf

Why doesn't a parallel query in parallel?

Hello

I hope someone can help me.

I tested (several times and different ways) to see if the parallel server will work and help on my queries.

My version is 11.2 on Solaris 10.

I have a table with more 100,000 records and set autotrace and calendar on for testing purposes.

I confirmed PARALLEL_MIN_SERVERS = 30 and PARALLEL_MAX_SERVERS = 160 and PARRALLEL_SERVERS_PER_CPU = 2.
(my server has 4 CPU)

I tested the full table running scan (select * from table) and time taken about 13:30 minutes.

Then, I changed the table and set 4 Parallels.
Run the test again and he ran more slowly (about 16 minutes).

Then I ran select / * + parallel (manual) * / and it was always about 14 minutes.

Then I ran select / * + parallel 4 * / and it took about 14:30 minutes.

Then I reset the degree of parallel to the table to 1.
Then, ran select / * + parallel 4 * / and it took a little less than 13:30 minutes.

So, it seems that it does not use any parallel query. Why not?

SQL> sho parameter cpu

NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ---------
cpu_count                            integer                          4
parallel_threads_per_cpu             integer                          2
resource_manager_cpu_allocation      integer                          4

SQL> sho parameter parallel

NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ---------
fast_start_parallel_rollback         string                           LOW
parallel_adaptive_multi_user         boolean                          TRUE
parallel_automatic_tuning            boolean                          FALSE
parallel_degree_limit                string                           CPU
parallel_degree_policy               string                           MANUAL
parallel_execution_message_size      integer                          16384
parallel_force_local                 boolean                          FALSE
parallel_instance_group              string
parallel_io_cap_enabled              boolean                          FALSE
parallel_max_servers                 integer                          160
parallel_min_percent                 integer                          0
parallel_min_servers                 integer                          30
parallel_min_time_threshold          string                           AUTO
parallel_server                      boolean                          FALSE
parallel_server_instances            integer                          1
parallel_servers_target              integer                          64
parallel_threads_per_cpu             integer                          2
recovery_parallelism                 integer                          0

SQL> sho parameter servers

NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ---------
max_shared_servers                   integer
parallel_max_servers                 integer                          160
parallel_min_servers                 integer                          30
parallel_servers_target              integer                          64
shared_servers                       integer                          1

PX COORDINATOR stage is something that you will see that when the plan uses parallel queries that are steps PX SEND QC (RANDOM) and PX BLOCK ITERATOR. You will also see that data in the column of PQ Distrib if parallel query is used. And the reference to the column of the IN-OUT backwards-> operations S indicates a transition between the parallel operations to the series (i.e. several parallel slaves, aggregated by one master series).

Justin

When you encounter ORA-12805: parallel query server died suddenly

What is the best practical appproach for dealiing with ORA-12805: parallel query server died suddenly?

$ oerr ora 12805
12805, 00000, "parallel query server died unexpectedly"
// *Cause: A parallel query server died unexpectedly, PMON cleaning
//         up the process.
// *Action: Check your system for anomalies and reissue the statement.
//          If this error persists, contact Oracle Support Services.
//          See trace file for more details.

ORA-12801: error reported in the P004 parallel query server

Hi all

I am using Oracle 10 g on Linux and I get the error msg below

  [sqlplus] ORA-12801: error signaled in parallel query server P004
  [sqlplus] ORA-01114: IO error writing block to file 201 (block # 612165)
  [sqlplus] ORA-27072: File I/O error
  [sqlplus] Linux-x86_64 Error: 11: Resource temporarily unavailable
  [sqlplus] Additional information: 4
  [sqlplus] Additional information: 612165
  [sqlplus] Additional information: 69632
  [sqlplus] ORA-01114: IO error writing block to file 201 (block # 612165)
  [sqlplus] ORA-27072: File I/O error
  [sqlplus] Linux-x86_64 Error: 11: Resource temporarily unavailable
  [sqlplus] Additional information: 4
  [sqlplus] Additional information: 612165
  [sqlplus] Additional information: 69632

Pls someone put light on this.

Thanks in advance
SAZ

Dear Saaz Ena,

I don't think that is related with the TEMP tablespace but you can run under query to discover their space;

SELECT NAME, TS#, BYTES/1024/1024 "Size in GB"
FROM V$TEMPFILE
ORDER BY 3 DESC;

Hope that helps.

Ogan

ORA-12801: error reported in the parallel query P002 Server

Hello

I get the below error

ORA-12801: error signaled in parallel query server P002
ORA-01722: invalid number

INSERT INTO TMP
                ( TABLE_NAME, COLUMN_NAME, ATTR,     
                    ATTRIBUTE, ATTRIBUTE_TYPE, ATTR_DESCRIPTION  ,     
                    CODE_NAME, CODE_DESCRIPTION,  LANGUAGE_CODE  )
SELECT 'BLDG', 'FEATURE_TYPE', NULL, NDV.PBL_VLS,
                'C', NDV.LONG_NAME,  ND.DOM_NM, ND.LONG_NAME,
                'ENG'
FROM DOM_VUL NDV, DOM ND
WHERE ND.DOM_NM = 'FEATURE'
AND NDV.VALUE >= 2005000 AND NDV.VALUE <=2005999 
AND ND.DOM_IDS = NDV.DOM_IDS;

When I comment on AND NDV. VALUE > = 2005000 AND NDV. VALUE < = 2005999 it works

Published by: Saaz Ena on March 11, 2010 21:11

Hello

It looks like NDV. VALUE contains values that is not a number, so you get this error.

Concerning

Why a parallel query use direct path read?
I think because the cache must Access pads, lock and lock on buffer block if parallel query do not reading of the direct path, parallel queries will be affected by the serialization as the latch and oracle .so lock mechanism choose direct path read to avoid what he.

that someone has a good idea?

Published by: Jeremiah on December 8, 2008 07:52
Jinyu wrote:
I think because the cache must Access pads, lock and lock on buffer block if parallel query do not reading of the direct path, parallel queries will be affected by the serialization as the latch and oracle .so lock mechanism choose direct path read to avoid what he.

Jinyu,

actually, Yes, I think that's it. The parallel query is designed to scan very much, because the load of communication between processes and maintenance/commissioning the parallel slave makes inefficient operation for small segments.

So I guess that the assumption is that the segment to analyze is probably very large, the fraction of the blocks in the buffer cache is very low compared to the blocks to scan and so the fresh reduction General read directly blocks without moving through all the questions of serialization of the buffer cache should prevail on the issue of blocks "unbuffered" and save the buffer for objects cache more benefit from development caching.

Kind regards
Randolf

Oracle related blog stuff:
http://Oracle-Randolf.blogspot.com/

SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676 /.
http://sourceforge.NET/projects/SQLT-pp/

Behavior of high N lines updated with subquery sessions and parallel

Hello
I have the following scenario:
{code}
SQL > create table aaa12 (date start_time, id1 number (1) Primary key, the number of status)
((1), buffer_id number (2) default null);
Table created.
SQL > insert into aaa12 (the value of start_time, id1, status)
trunc(sysdate-level) select 2, level 6, 1 double
3. connect by level < 6;
5 rows created.
SQL > validation
2;
Validation complete.
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 1
JUNE 8, 13 3 1
JUNE 7, 13 2 1
JUNE 6, 13 1 1
SQL > update aaa12
2 set buffer_id = 1,
3 status = 2
4 where in (select id1 id1
5 of (select id1
aaa12 6
7 where status = 1
Order 8 by start_time ASC)
9 where rownum < = 2)
10 - and status = 1
11;
2 lines to date.
{code}
Notice that I have not yet commit.
Now on a 2nd session I play the same update, only set buffer_id = 2:
{code}
SQL > update aaa12
2 set buffer_id = 2,
3 status = 2
4 where rowid in (select rowid
5 of (select rowid
aaa12 6
7 where status = 1
Order 8 by start_time ASC)
9 where rownum < = 2)
10 - and status = 1
11;
{code}
Expectations of update above (locked). Now let's commit the 1st session:
{code}
Validation complete.
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 1
JUNE 8, 13 3 1
JUNE 7, 13 2 2 1
JUNE 6, 13 1 2 1
SQL >
{code}
and we'll see what happened during the 2nd session:
{code}
2 lines to date.
SQL >-after 1st session committed
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 1
JUNE 8, 13 3 1
JUNE 7, 13 2 2 2
JUNE 6, 13 1 2 2
SQL >
{code}
It updated the same lines, even if their status should no longer be 1 committed after 1st session.
I guess what happens is that the subquery is performed on the time of execution of the update statement - which means that the subquery is read so coherent to reinstate the same lines.
but now if I do the same thing, but a comment the external status = 1 as part of the where the update in addition to the subquery - it seems to work:
I dropped the table, recreated, inserted the same 5 lines and now start the new updates:
{code}
SQL > update aaa12
2 set buffer_id = 1,
3 status = 2
4 where in (select id1 id1
5 of (select id1
aaa12 6
7 where status = 1
Order 8 by start_time ASC)
9 where rownum < = 2)
10 and status = 1
11;
2 lines to date.
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 1
JUNE 8, 13 3 1
JUNE 7, 13 2 2 1
JUNE 6, 13 1 2 1
{code}
updated even with buffer_id = 2 on 2nd session:
{code}
SQL > update aaa12
2 set buffer_id = 2,
3 status = 2
4 where rowid in (select rowid
5 of (select rowid
aaa12 6
7 where status = 1
Order 8 by start_time ASC)
9 where rownum < = 2)
10 and status = 1
11;
{code}
session is locked, now after commit 1st session - session 2 updated and table looks like:
{code}
2 lines to date.
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 2 2
JUNE 8, 13 3 2 2
JUNE 7, 13 2 2 1
JUNE 6, 13 1 2 1
{code}
I have 2 questions:
1. How is the 2nd scenario works and the subquery does not limit the update for the same 2 lines so that the update will update anything?
2 in case I have a table with many rows and I need to process the records in order, but want to do it in parallel - if I have 1000 lines of process and each session can handle 500 - I don't want to wait for the other, but work on different lines simultaneously. Is this possible without having to open a cursor with a SELECT... UPDATE SKIP LOCKED? because then I would have more than 500 lines of loop and do an update by records, which seems unwise to good performance.
Any help/advice would be appreciated.
Thank you
-Mor

Sorry, I missed a major difference between the two cases. And it's write consistency. There are some situations where UPDATE or DELETE are realizing that they cannot maintain consistency of statement-level and are forced to do a restore 'mini' (which may not be so "tiny") and start over. One of these cases is as follows. We have a UPDATE/DELETE with a WHERE clause. So we start to extract the rows that match WHERE clause. And we meet a line whose value to adapt the WHERE clause when statement has started now, but it is not. And that's exactly what is happening here. When the session 2 publishes the UPDATED session 1 did not err again. As a result, lines of June 6 & 7 correspond to the WHERE clause and must therefore be updated. However, they are locked by session 1. When the session commits 1, locks are released and session 2 could proceed with the updating of these two lines. However, to write rules of coherence mandate session 2 to check if WHERE clause is always true and realize that it's not. This causes a mini-restauration and UPDATE again. Now sinus session already committed 1, session 2 sees all of the changes and lines of June 6 & 7 do not match WHERE clause more (status = 2). So first of all (by START_TIM) two rows with STATUS = 1 are now June 8 & 9. That is why the session 2 updates the.

SY.

Parallel query Server BI (with DOP > 1)?
Hi guys,.

I have some performance problems with certain reports. These reports are very siple, no aggregation, no action... a few columns from different dimensions.
The problem is that the size of her varied dimensions of 1 million 10 million records and some dimensions are linked by relationships "outer join". The physical motion generated by the BI server takes about 22 minutes, but if I change the same query by adding the paralellism for the tables involved (for example select / * + PARALLEL (mytable 4) * /...) I get the result in 5 minutes (1/4 of the time).

So is it possible to force the BI server to use a degree (DOP) > 1 for all/some physical tables?

What about using index (I have not create any index again, maybe I should start to use for the primary/foreign keys)?

Of course, other solutions for this problem are appretiated! :-)

Thanks in advance,
Nazza
Nazza,

Have you tried the HINT function (physical Table-> > general tab-->> HINT) available in the physical layer. You can use parallel index it and the generated query would use the same throughout, shooting it to the database.
Indexex are good to have but to check with your DBA, what rating would be more profitable to your query.

See you soon
Blackburn

VISA lib parallel query the former instrument 488

I looked around to see if there is an answer for this, but I can't seem to find. I want to use the VISA library to communicate with an Amplitude of Phase Scientific Atlanta 1780 receiver, and I need to be able to read the status byte parallel survey (a special status byte is made available only through parallel survey, not poll serial). I was not able to find a function in the VISA library that can do. Is there a function I am missing, or is there another way to do it?

Thank you

Victor

Documentation so that it should have been included when you installed the driver NOR-488. 2.

Because, in my experience, the parallel survey is rarely used, very low level function, it is possible that it does not have visa. Conversion to series survey to see your instrument is a possible workaround.

Why can't I run this query in parallel?

DB version: 11.2.0.4
Platform: Oracle Linux 6.5
In my DB, a job with parallelism 5 as stats collection below works well. OEM, I confirm that the bottom congregate, stats job runs with 5 slave process.
exec dbms_stats.gather_table_stats (-)
ownname = > 'MEA ', -.
tabname = > "ORDER_DETAIL", -.
estimate_percent = > DBMS_STATS. AUTO_SAMPLE_SIZE, -.
Cascade = > TRUE;
method_opt = > 'for all THE COLUMNS of SIZE AUTO ', -.
degree = > 5);
Order_Detail is a table with 400 million records. I wanted to get a number of rows in this table. So, I tried to use parallelism as shown below.
But the process of slaves were not created. The SELECT query worked only with parallelism 1. I have this cofirmed of data in real-time to OEM and gv$ view px_session.
SQL > show parameter parallel_max_servers
VALUE OF TYPE NAME
------------------------------------ ----------- ------------------------------
PARALLEL_MAX_SERVERS around 3200
SQL > ALTER SESSION FORCE PARALLEL QUERY 5 PARALLELS;
Modified session.
SQL > ALTER SESSION enable parallel query.
Modified session.
SQL > select / * + PARALLEL (5) * / count (*) from ptms.order_detail;
-Also tried
Select / * + PARALLEL(ptms.order_detail,5) * / count (*) from ptms.order_detail;
-Also tried
ALTER SESSION ENABLE PARALLEL DML.
-Setting below must not be the cause. Right? ALTER SESSION command must take precedence over this setting. Right?
SQL > select table_name, DEGREE from dba_tables where owner = 'MEA' and table_name = "ORDER_DETAIL";
DEGREE OF TABLE_NAME
------------------------------ ----------------------------------------
ORDER_DETAIL 1

Have you tried the trick

SELECT / * + PARALLEL * / COUNT (*)...

Inverse of command 'ALTER SESSION SET.

Hello
I have a READER user and when I connected with this user that I can set the current session settings such as
```
alter SESSION set smtp_out_server = '123.345.134.123';
```
or
```
alter session force parallel query parallel N;
```
If it would be sysdba or any other user with grant on parameter $ v we could use:
```
select value from v$parameter where name = 'smtp_out_server'
```
Is it possible that I can get the current session settings without going through subsidies on the parameter $ v?
PS: it seems strange, that we have the setter (alter session set), but haven't Get accessor.

Maybe the function dbms_utility.get_parameter_value, assuming that you have the privileges.

Deleting huge records with parallel option in a non-partitioned table
Hi all

Is it possible to run delete statement with sub query that removes millions of records in a table that is not partitioned with parallel option?

SQL > Alter session enable parallel query.

SQL > Alter session enable parallel dml.

SQL > alter table table_A parallel 5;

SQL > delete the table_A where colA = "zzzz";

SQL > commit;

SQL > alter table table_A noparallel;

Please advice,

Thanks in advance.
user7280060 wrote:
Hi all

Is it possible to run delete statement with sub query that removes millions of records in a table that is not partitioned with parallel option?

SQL > Alter session enable parallel query.

SQL > Alter session enable parallel dml.

SQL > alter table table_A parallel 5;

SQL > delete the table_A where colA = "zzzz";

SQL > commit;

SQL > alter table table_A noparallel;

Please advice,

Thanks in advance.

Yes

Move the table in same tablespace is not reorganize the data

Hello.
I am facing a problem that I have not used to have. First of all, a description of our envorinnement:
We have a few large tables partitioned and performance optimization, our ETLs use bluk, add notes, parallelism and so on. This create several holes of unused space in tablespaces/data files as well a kind of leak of space on our drives.
A complete correction would re-create the tablespaces move everything is of opposes another. It would be impratical, because there are about 15 who are top of 100 GB; the time and effort to recreate everything is not affordable for the Business.
Instead, we have a single proc that comes to calculate the actual amount of used space (converted to blocks) and makes a move of all objects above this block_id. Just after this operation, there is a dynamic shrink based on the new HWM (given that the objects have been moved) on the data file freeing disk space. As we have a datafile by tablespace and a tablespace by schema, we would like to keep this body, if we make a single movement for objects, like 'ALTER TABLE' | owner: '. ' || nom_segment | "MOVE; "(the complete query works with all types of data such as partitions of table objects, the index partitions and the subpartions). This will move the object in the same space for the first freespace on the tables and free up space at the end of the file to shrink. In theory.
This unique proc used to work properly. In a 650 GB GB 530 tablespace in use moving about 20 that Go (the amount of data beyond the HWM 530 GB) is simpler than to create a new file/TBS and the displacement of 20 GB is faster than Go 530.
But suddenly things changed when some TBS refused to be narrowed. What I found out: the command move doesn't fail, it works very well and Oracle really moves the object. But for reasons that I don't know, he's not moving it at the beginning of the file, it keeps the object at the end. So the da calculates the new HWM, but because some objects that were in the tail of the queue, the shrink is done with a very high HWM, if no real space is reclaimed.
So, the main question: How does the ALTER TABLE FOO MOVE really works? I thought that it would be always to move the object to the beginning of the file thus reorganize, but I analyzed the last objects that gave me this problem (block_id before and after the move, compared to block_ids empty and everything) and actually, I see that they were moved at the end of the file, although there is enough space to accommodate initially.

Okay, I think I found the problem. Before that I just pulled the script as posted, but then I had the good idea to improve its performance with parallelism, so I added:

ALTER SESSION FORCE PARALLEL QUERY 16 PARALLELS;

ALTER SESSION FORCE PARALLEL DDL PARALLEL 16;

ALTER SESSION FORCE PARALLEL DML PARALLEL 16;

Returning to prallel not running, that I could reuse the freespace on the beginning of the file, and then narrow it down.

Obviously, each writing data in parallel mode reuse freespace, I just forgot that a TABLE ALTER MOVE is also a data write operation. I fell a bit ridiculous, caught in the same trap that I was trying hard.

Thank you all for the comments and advice.

Primary key question

Hello

database version is GR 11, 2; We moved a large table of 12 million records from database 1 database 2. That's how the developers moved:

create the table temp_engine in select * engine;

Then re-named table temp_engine of the engine; but with this method, the primary key and the markings on table engine not copied. If we lose primary key and indexes on table engine. We want to add primary key and indexes, while the application is running. It's high system, busy with many inserts/updates / select on table engine; data are entered into the engine table every 10 minutes;

Issues related to the:

1 - the addition of pk would take time and can slow down the database?
2 - what kind of locks, if any, we will have when adding the primary key and index?
3. in the case, we will have the locks when adding the index/pk; the inserts will not happen until the locks to be released just?

Thank you very much
Diego

Published by: Diego 16 April 2012 07:19

In your first post, you said that your developer have moved (basically it's not moving, rather a copy) by:
create the table temp_engine in select * engine; the first second db db and now wish you that this new temp_engine has same constraint, privileges, statistics as well as the right table engine? At the same time table is very used in the comic book then, it must avoid any lock or lack of temp straight segment like that?

So, please check the example below, where you can use EMP as temp_engine and INT_TAB as table of this db engine... after the end of the process, you can simply file temp_engine, rename INT_TAB as an engine.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create table int_tab as select * from emp where 1=2;

Table created.

SQL> select grantee,privilege from user_tab_privs where table_name='EMP';

GRANTEE                        PRIVILEGE
------------------------------ ----------------------------------------
HR                             SELECT
HR                             UPDATE

SQL> begin
  2  DBMS_REDEFINITION.CAN_REDEF_TABLE('scott','emp',
  3  DBMS_REDEFINITION.CONS_USE_PK);
  4  end;
  5  /

PL/SQL procedure successfully completed.

SQL> alter session force parallel dml parallel 4;

Session altered.

SQL> alter session force parallel query parallel 4;

Session altered.

SQL> BEGIN
  2  DBMS_REDEFINITION.START_REDEF_TABLE(
  3  uname       => 'SCOTT',
  4  orig_table  => 'EMP',
  5  int_table   => 'INT_TAB');
  6  END;
  7  /

PL/SQL procedure successfully completed.

SQL> DECLARE
  2  num_errors PLS_INTEGER;
  3  BEGIN
  4  DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(
  5  'SCOTT','EMP','INT_TAB',DBMS_REDEFINITION.CONS_ORIG_PARAMS,
  6  TRUE, TRUE, TRUE, FALSE, num_errors, TRUE);
  7  END;
  8  /

PL/SQL procedure successfully completed.

SQL> BEGIN
  2  DBMS_REDEFINITION.SYNC_INTERIM_TABLE('SCOTT', 'EMP', 'INT_TAB');
  3  END;
  4  /

PL/SQL procedure successfully completed.

SQL> BEGIN
  2  DBMS_REDEFINITION.FINISH_REDEF_TABLE('SCOTT', 'EMP', 'INT_TAB');
  3  END;
  4  /

PL/SQL procedure successfully completed.

SQL> select grantee,privilege from user_tab_privs where table_name='INT_TAB';

GRANTEE                        PRIVILEGE
------------------------------ ----------------------------------------
HR                             SELECT
HR                             UPDATE

SQL> select constraint_name,constraint_type,table_name from user_constraints where table_name in ('EMP','INT_TAB');

CONSTRAINT_NAME                C TABLE_NAME
------------------------------ - ------------------------------
PK_EMP                         P EMP
FK_DEPTNO                      R EMP
TMP$$_PK_EMP0                  P INT_TAB
TMP$$_FK_DEPTNO0               R INT_TAB

So, at this point, my INT_TAB is just a clone of the EMP table. Even statistics, the privileges and the constraints of the EMP have been applied to INT_TAB. Now, at this point you can drop temp_engine table and can use INT_TAB as an engine.

Hope I am clear in my answer, if it is not then please keep also close the message.

Concerning
Girish Sharma

Session of parallel query of murder

Similar Questions

Maybe you are looking for