Reg: Error in Parallel Hint -

Hi Experts,
I have a concern regarding the usage of parallel hint with DOP = "AUTO".
Getting these errors while the ETL job(s) are executed with /*+ PARALLEL(AUTO) */
JOB - 1
java.sql.SQLException: ORA-12853: insufficient memory for PX buffers: current 1159024K, max needed 11666304K
ORA-04031: unable to allocate 65560 bytes of shared memory ("large pool","unknown object","large pool","PX msg pool")
JOB - 2
java.sql.SQLException: ORA-12801: error signaled in parallel query server P256
ORA-12853: insufficient memory for PX buffers: current 1159024K, max needed 11666304K
ORA-04031: unable to allocate 65560 bytes of shared memory ("large pool","unknown object","large pool","PX msg pool")
I tried google but couldn't get an appropriate reason for this and also fix.
1- Do I need to increase some memory buffer related parameter?
2- Does "AUTO" option causing this? And will using a DOP = 3, 4, etc. guarantee to fix this?
(I will try this and check but want to know the exact reason, so that it doesn't cause any problem in Prod)
Any pointers regarding this.
-- Ranit
( on Oracle 11.2.0.3.0 )

ranit B wrote:
Getting these errors while the ETL job(s) are executed with /*+ PARALLEL(AUTO) */
JOB - 1
java.sql.SQLException: ORA-12853: insufficient memory for PX buffers: current 1159024K, max needed 11666304K
ORA-04031: unable to allocate 65560 bytes of shared memory ("large pool","unknown object","large pool","PX msg pool")
JOB - 2
java.sql.SQLException: ORA-12801: error signaled in parallel query server P256
ORA-12853: insufficient memory for PX buffers: current 1159024K, max needed 11666304K
ORA-04031: unable to allocate 65560 bytes of shared memory ("large pool","unknown object","large pool","PX msg pool")
I tried google but couldn't get an appropriate reason for this and also fix.
1- Do I need to increase some memory buffer related parameter?
2- Does "AUTO" option causing this? And will using a DOP = 3, 4, etc. guarantee to fix this?
(I will try this and check but want to know the exact reason, so that it doesn't cause any problem in Prod)
Any pointers regarding this.
-- Ranit
( on Oracle 11.2.0.3.0 )
The error message is pretty self-explanatory: The memory that is required for communication between PX Servers ("PX msg pool") can either be allocated from the Shared Pool or the Large Pool - depending on some other settings. In your case obviously the memory is taken from the Large Pool, and the error message says that it needs approx. 12GB of memory from the Large Pool which isn't available. I'm not sure however if that error message is really showing a reasonable "needed" value because 12GB for the "PX msg pool" is much more than what you should get for reasonable DOP values according to the underlying formula.
So you either need to change the settings (depends on how the memory is configured / static allocation or *target* parameters and the parallel_automatic_tuning (deprecated) parameter, internally the "_PX_use_large_pool" parameter) to move the allocation to the Shared Pool, or much simpler, increase the size of the Large Pool accordingly.
Although I doubt the "needed" value of 12GB you should nevertheless review your AUTO DOP parameter settings since the values shown for the "PX msg pool" could indicate that the DOP chosen seems to be pretty high. You can find that information in the "Notes" section when you get the corresponding plan from the Library Cache using "DBMS_XPLAN.DISPLAY_CURSOR", or using EXPLAIN PLAN and DBMS_XPLAN.DISPLAY, or may be even from AWR if you have the license using DBMS_XPLAN.DISPLAY_AWR.
For example it might make sense to lower your PARALLEL_DEGREE_LIMIT parameter value to some explicit value rather than using the default value of CPU. Also you should review your I/O calibration results in the DBA_RSRC_IO_CALIBRATE view - and there the MAX_PMBPS value. This is the relevant value that is used to determine the DOP - see my blog post Oracle related stuff: Cost Is Time: Next Generation
Randolf

Similar Messages

  • Parallel hint in OBIEE 11g

    Dear All,
    I am new to OBIEE. Can any one tell me how to add parallel hint in 11g. Is Oracle BI Presentation Service ignores any DB Hint added to query while parsing. If yes, how to overcome this. We need to add parallel hint in few report to make things faster, i do not want to touch the table level hints as it is affecting my performance.
    I have gone through oracle doc ID 823193.1
    Thanks and Regards,
    Anand.

    Hi Jay,
    Thanks for your reply.
    can you please give a practical example by working in a sqlplus. I tried and got below error. Please help.
    SQL>  select * from t;
             N
             1
    SQL>  select n from t;
             N
             1
    SQL> select /*+PARALLEL (t,2)*/ n from t;
             N
             1
    SQL>  select EVALUATE('/*+PARALLEL (t,2)*/',t."n") from t;
    select EVALUATE('/*+PARALLEL (t,2)*/',t."n") from t
    ERROR at line 1:
    ORA-00904: "T"."n": invalid identifierRegards,
    Anand.

  • Parallel hint as part of index not working

    Hello,
    I think that I am misusing the parallel hint on this one, and would appreciate some guidance. I have an insert statement as such:
    INSERT INTO TABLE1
    SELECT column1, column2
    FROM table2;
    I modified the query so that it has a parallel:
    SELECT /*+ FULL(table2) PARALLEL(table2, 4) */
    column1, column2
    FROM table2;
    This parallel helps with the query's speed. However, when I use it with the insert statement on the top, it does not insert any record, nor does it give an error message:
    INSERT INTO TABLE1
    SELECT /*+ FULL(table2) PARALLEL(table2, 4) */
    column1, column2
    FROM table2;
    I put EXECUTE IMMEDIATE 'ALTER SESSION ENABLE PARALLEL DML'; at the beginning of the procedure, but that did not help.
    I really need the parallel to be in the SELECT statement, that statement runs for about 3 hours without a parallel (due to large amounts of data - no problems with query itself), however it returns only about 10,000 records, and I don't need to insert those with a parallel hint.
    Edited by: user577453 on Mar 17, 2009 12:25 PM -- Added last paragraph.

    user577453 wrote:
    I think that I am misusing the parallel hint on this one, and would appreciate some guidance. I have an insert statement as such:
    I put EXECUTE IMMEDIATE 'ALTER SESSION ENABLE PARALLEL DML'; at the beginning of the procedure, but that did not help.
    I really need the parallel to be in the SELECT statement, that statement runs for about 3 hours without a parallel (due to large amounts of data - no problems with query itself), however it returns only about 10,000 records, and I don't need to insert those with a parallel hint.First of all, your subject is probably supposed to be "Parallel hint as part of *insert* not working" rather than "Parallel hint as part of *index* not working", am I right?
    Can you show us the EXPLAIN PLAN output you get for your query and the one you get for your INSERT when using the parallel hints as posted?
    Please mention your database version (4-digits, e.g. 10.2.0.3).
    Please use DBMS_XPLAN.DISPLAY to format the EXPLAIN PLAN output if you're already on 9i or later, and please use the \ tag before and after the DISPLAY output to format it in fixed font for readability.
    What seems to be odd that you say that the result of the query seems to be different when using it as part of the INSERT statement? Are you sure that running the query standalone returns data whereas using exactly the same query in the INSERT statement inserts no records? This would be buggy behaviour.
    Regards,
    Randolf
    Oracle related stuff blog:
    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/                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Parallel Hint !!

    Hello Gurus
    I m using prallel hint ...i belive the syntax of parallel hint is something like this
    /*+ Parallel(tablename, degree) */But when i try with just degree without tablename, it works absolutely fine .... So my question is can i use parallel hint without tablename jus by mentioning degree
    ..like this
    /*+    parallel(32) */My concern is, the query is has been deployed to production without the tablename being mentioned in parallel hint....so how serious is this ?? BUt when i run the query in dev without table name mentioning in parallel hint in Development area its running fine ...
    So do u guys hav any suggestions!!
    Thanks !!
    Edited by: user642297 on May 26, 2010 11:13 AM

    user642297 wrote:
    I'm surprised it works without tablename (or alias for that tablename).
    Yes it did work ...it did not through me any error!!
    Hints that don't work because the syntax is not correct are just comments, they do not generate any errors.
    SQL> select count(*) from
      2  (select o.owner, count(*) from all_objects o,
      3    (select level from dual connect by level <= 5)
      4     group by o.owner);
      COUNT(*)
           176
    Elapsed: 00:01:07.01
    SQL> edi
    Wrote file afiedt.sql
      1  select /*+ go_faster */ count(*) from
      2  (select o.owner, count(*) from all_objects o,
      3    (select level from dual connect by level <= 5)
      4*    group by o.owner)
    SQL> /
      COUNT(*)
           176
    Elapsed: 00:01:12.57

  • Effects of PARALLEL hint in different parts of SQL script

    I have a fairly large data warehouse with most of the Child tables having more than 5 billion rows. They are partitioned by a DATE column.
    I have several local B-tree and bitmap indexes on the appropriate columns.
    The DEGREE on most of the large tables is currently set to 4.
    AUTO_DOP is not currently being used.
    The DW runs on a 64 processor server with 64GB memory and 16k block size.
    Database is Oracle 11.2.0.2 EE on Solaris
    I have several queries that extract data into separate reference tables that are totally refreshed on typically a monthly basis although a few are daily.
    The queries use an INSERT /*+ APPEND */ and usually are a JOIN of 3-4 tables and/or in-line views with a GROUP BY on 1-2 columns.
    I'm trying to find the best place to specify a PARALLEL hint or optionally force parallel DML in the session and set the degree via the 'ALTER SESSION ...' statement.
    Here are the options I'm looking at: (others are greatly appreciated!)
    1) use the /*+ PARALLEL x */ hint only on the topmost SELECT
    2) specify the /*+ PARALLEL x */ hint on each separate SELECT in all the sub-queries and in-line views where it's deemed useful (i.e. not on very small tables).
    3) use an 'ALTER SESSION FORCE PARALLEL DML PARALLEL x;'
    Questions:
    a) by using option (1) will the DOP in that topmost SELECT be used for all subsequent SELECT statements below it?
    b) same question for using option (3)?
    c) how can I monitor the activity and verify what DOP is used in the different query sections? I have tried to follow the script execution in TOAD but haven't had much luck.
    Thanks very much for your help and please let me know if you need any more information.
    -gary

    garywicke wrote:
    Thanks for the feedback! Very useful!
    A couple of follow-ups.
    My SQL statement structure is basically like this:
    INSERT /*+ APPEND  PARALLEL (8) */  INTO <table 1> (COL1, COL2, COL3)
    SELECT /*+ PARALLEL (24) */ COL1, COL2, COL3
    FROM <table 2>
    WHERE ...
    GROUP BY ...
    I just checked the docs. The syntax for the parallel hint listed for 10gR1 (could have changed for 11gR2 - go ahead and see for yourself)
    parallel(table_spec[degree]expecting a table designation and an optional degree. If your syntax is unrecognized the hint will be ignored
    It is possible the syntax you are using is valid, being listed elsewhere than the hint definitions. Some hints aren't listed where hints are defined but in the data warehousing guide and so are semi-documented. I have not seen that usage myself.
    >
    After reading about 'ALTER SESSION ENABLE PARALLEL DML', I can see how to set it but I can't see how to verify it's current state (enabled or disabled). I looked at several system parameters but it wasn't obvious to me. I did see some PARALLEL_MAX_SERVERS (100) and PARALLEL_MIN_SERVERS (0) but didn't know if that applied to any and all SQL statements, including DML which is what I'm doing.I don't know how to tell if parallel DML is enabled with ALTER SESSION ENABLE PARALLEL DML except by turning it on. using SHOW PARAMETERS PARALLEL in SQL*PLUS did not tell me anything when I just tried it. You should be able to turn it on and get an indication from an execution plan that it is being used.

  • Is using Parallel Hint /*+PARALLEL */  good or bad?

    Hi,
    I am facing problem in using /*+ PARALLEL */ hint in SQL Query its taken long time to execute.
    Is using PARALLEL Hint degrades performance?
    The Table FCT_TABLE is having PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT ) clause.
    We are using parallel hint as SELECT /*+ PARALLEL(FCT_TABLE 2)
    Any help will be needful for me.
    Thanks and Regards

    user598986 wrote:
    We have noticed the following from the Server:
    1.The Disk I/O is showing 0 always during the time of Execution of the Query.
    2.The I/O Adapter is showing 700%.What is the o/s and version? Do you use any virtualisation? What storage system do you use? What RAID levels, if any? And how did you monitor these results?
    Note that the physical I/O layer is not part of the database layer. From the database layer you typically address I/O issues with
    - logical design (e.g. normalise data so that there's a single copy of the data to maintain and thus less I/O)
    - physical design (e.g. use partitioning, IOTs, clusters, indexes and so on to facilitate less I/O to process data)
    - parallelise (use multiple processes to perform large I/O scans to address some of the inherited latency issues when doing I/O)
    - reduce I/O (e.g. by truncating a table or partition instead of deleting it, using CTAS, design s/w that only needs to make a single pass through a data set, etc)
    From the database app level you have no control over where the data is stored, how it is stored and cached. So, as PL/SQL or app developer, your primary concern should be the amount of I/O your data model and app needs - as that is something you can and do control. And not worry about the physical implementation of the I/O layer. As that should be the concern of the sys admin and DBA of that platform.

  • Avoiding Parallel hints on a view

    Hi All,
    I am trying to avoid using Hints on a view.
    Database: 11gr2.
    Scenario:
    I created a view
    CREATE OR REPLACE VIEW customer_count_vw
    AS SELECT /*+ NO_PARALLEL(T) */ COUNT(1) FROM customer;
    When I see the explain plan it is going for a FULL TABLE Scan.
    But When I use a hint on top of the view like
    SELECT /*+ PARALLEL(A,12) */ * FROM customer_count_vw;
    The explain plan is using the PARALLEL Hint.
    Is there any way we can avoid this hint being applied on this view.
    The reason why we want this scenario is , we are going to expose the view to the external people and if they force PARALLEL on the view, it will give a lot of problem for us in the PRODUCTION environment.
    Appreciate your response.
    THANKS,
    MK.

    >
    we are going to expose the view to the external people and if they force PARALLEL on the view, it will give a lot of problem for us in the PRODUCTION environment.
    >
    You can't keep a query writer from using a PARALLEL hint in a query. But you can add a LOGON trigger that disables PARALLEL execution for the user sessions that you don't want to perform parallel ops. If you do that then PARALLEL will not be used for any other queries that session uses.

  • USE_HASH vs Parallel Hints

    Hi,
    I am working on performance of a query. The Earlier Query was using Parallel Hint with Degree 8 which was using lot of CPU utilization. Now I have replaced that with USE_HASH hint. Which one is more expensive. The Parallel Hint was there in 2 tables, but I have used USE_HASH hint on all 8 table which are there in From Clause.
    Please tell me which one is expensive out of there 2?

    They are hints with different purposes.
    The USE_HASH specifies the Join Method.
    The PARALLEL specifies the Retrieval method.
    You can have
    a. a HASH Join without using Parallel Query
    b. a PARALLEL Query fetch without using a HASH Join
    c. a HASH Join that uses a Parallel Query
    OR, without any Hints, assuming that the Optimizer can generate an optimal plan
    d. Neither Parallel Query NOR Hash Join
    Which is optimal really depends on the nature of the data being queried and the nature of the query itself.
    Hemant K Chitale
    http://hemantoracledba.blogspot.com

  • PARALLEL hint problem

    Hi All,
    I tuned a query which ran for 7 hours. The query has 9 unions.
    After tuning using PARALLEL hint (I just placed as /*+PARALLEL */ in the select statement.)
    It took 2 hours of execution time.
    Now my client refreshed the instance which caused increase of 20% of data.
    Now the query is taking 20 hours to execute even after using parallel hint. Can anyone tellme the cause of this increase in time?
    Also plz tellme wat r the things that i need to check the server in dba prespective?
    (In this i mentioned as a query actually it resides in a procedures which uses cursors)
    Thanks in advance...

    <pre>Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE (Cost=15770 Card=1 Bytes=3
    22)
    1 0 SORT (GROUP BY) (Cost=15770 Card=1 Bytes=322)
    2 1 NESTED LOOPS (Cost=15723 Card=1 Bytes=322)
    3 2 NESTED LOOPS (Cost=15722 Card=1 Bytes=312)
    4 3 NESTED LOOPS (Cost=15720 Card=1 Bytes=280)
    5 4 NESTED LOOPS (Cost=15718 Card=1 Bytes=271)
    6 5 NESTED LOOPS (Cost=15715 Card=1 Bytes=239)
    7 6 NESTED LOOPS (Cost=15714 Card=1 Bytes=208)
    8 7 NESTED LOOPS (Cost=15712 Card=1 Bytes=195)
    9 8 HASH JOIN (Cost=5053 Card=3553 Bytes=56492
    7)
    10 9 HASH JOIN (Cost=1732 Card=17723 Bytes=21
    09037)
    11 10 NESTED LOOPS (Cost=7 Card=26 Bytes=234
    0)
    12 11 NESTED LOOPS (Cost=2 Card=1 Bytes=60
    13 12 TABLE ACCESS (BY INDEX ROWID) OF '
    FA_DEPRN_PERIODS' (Cost=1 Card=1 Bytes=26)
    14 13 INDEX (UNIQUE SCAN) OF 'FA_DEPRN
    PERIODSU3' (UNIQUE)
    15 12 TABLE ACCESS (BY INDEX ROWID) OF '
    FA_BOOK_CONTROLS' (Cost=1 Card=1 Bytes=34)
    16 15 INDEX (UNIQUE SCAN) OF 'FA_BOOK_
    CONTROLS_U1' (UNIQUE)
    17 11 TABLE ACCESS (FULL) OF 'FA_CATEGORY_
    BOOKS' (Cost=5 Card=26 Bytes=780)
    18 10 TABLE ACCESS (FULL) OF 'FA_ASSET_HISTO
    RY' (Cost=1723 Card=665635 Bytes=19303415)
    19 9 TABLE ACCESS (FULL) OF 'FA_DISTRIBUTION_
    HISTORY' (Cost=2223 Card=1344720 Bytes=53788800)
    20 8 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEPRN
    _DETAIL' (Cost=3 Card=1 Bytes=36)                                                        
    21 20 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_DETAIL_
    U1' (UNIQUE) (Cost=2 Card=1)
    22 21 SORT (AGGREGATE)
    23 22 FIRST ROW (Cost=4 Card=14 Bytes=336)
    24 23 INDEX (RANGE SCAN (MIN/MAX)) OF 'F
    A_DEPRN_DETAIL_U1' (UNIQUE) (Cost=4 Card=3052321)
    25 20 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEP
    RN_PERIODS' (Cost=1 Card=1 Bytes=25)
    26 25 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIO
    DS_U3' (UNIQUE)
    27 20 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEP
    RN_PERIODS' (Cost=1 Card=1 Bytes=25)
    28 27 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIO
    DS_U3' (UNIQUE)
    29 20 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEP
    RN_PERIODS' (Cost=1 Card=1 Bytes=25)
    30 29 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIO
    DS_U3' (UNIQUE)
    31 20 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEP
    RN_PERIODS' (Cost=1 Card=1 Bytes=25)
    32 31 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIO
    DS_U3' (UNIQUE)
    33 20 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEP
    RN_PERIODS' (Cost=1 Card=1 Bytes=25)
    34 33 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIO
    DS_U3' (UNIQUE)
    35 20 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEP
    RN_PERIODS' (Cost=1 Card=1 Bytes=25)
    36 35 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIO
    DS_U3' (UNIQUE)
    37 20 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEP
    RN_PERIODS' (Cost=1 Card=1 Bytes=25)
    38 37 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIO
    DS_U3' (UNIQUE)
    39 20 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEP
    RN_PERIODS' (Cost=1 Card=1 Bytes=25)
    40 39 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIO
    DS_U3' (UNIQUE)
    41 7 TABLE ACCESS (BY INDEX ROWID) OF 'GL_CODE_CO
    MBINATIONS' (Cost=2 Card=1 Bytes=13)
    42 41 INDEX (UNIQUE SCAN) OF 'GL_CODE_COMBINATIO
    NS_U1' (UNIQUE) (Cost=1 Card=1)
    43 6 TABLE ACCESS (BY INDEX ROWID) OF 'FA_CATEGORIE
    S_B' (Cost=1 Card=1 Bytes=31)
    44 43 INDEX (UNIQUE SCAN) OF 'FA_CATEGORIES_B_U1'
    (UNIQUE)
    45 5 TABLE ACCESS (BY INDEX ROWID) OF 'FA_BOOKS' (Cos
    t=3 Card=1 Bytes=32)
    46 45 INDEX (RANGE SCAN) OF 'FA_BOOKS_N1' (NON-UNIQU
    E) (Cost=2 Card=1)
    47 45 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEPRN_PER
    IODS' (Cost=1 Card=1 Bytes=25)
    48 47 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIODS_U3'
    (UNIQUE)
    49 45 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEPRN_PER
    IODS' (Cost=1 Card=1 Bytes=25)
    50 49 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIODS_U3'
    (UNIQUE)
    51 45 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEPRN_PER
    IODS' (Cost=1 Card=1 Bytes=25)
    52 51 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIODS_U3'
    (UNIQUE)
    53 45 TABLE ACCESS (BY INDEX ROWID) OF 'FA_DEPRN_PER
    IODS' (Cost=1 Card=1 Bytes=25)
    54 53 INDEX (UNIQUE SCAN) OF 'FA_DEPRN_PERIODS_U3'
    (UNIQUE)
    55 4 TABLE ACCESS (BY INDEX ROWID) OF 'FA_ADDITIONS_B'
    (Cost=2 Card=1 Bytes=9)
    56 55 INDEX (UNIQUE SCAN) OF 'FA_ADDITIONS_B_U1' (UNIQ
    UE) (Cost=1 Card=1)
    57 3 TABLE ACCESS (BY INDEX ROWID) OF 'FA_ADDITIONS_TL' (
    Cost=2 Card=1 Bytes=32)
    58 57 INDEX (UNIQUE SCAN) OF 'FA_ADDITIONS_TL_U1' (UNIQU
    E) (Cost=1 Card=1)
    59 2 TABLE ACCESS (BY INDEX ROWID) OF 'FA_ASSET_KEYWORDS' (
    Cost=1 Card=1 Bytes=10)
    60 59 INDEX (UNIQUE SCAN) OF 'FA_ASSET_KEYWORDS_U1' (UNIQU
    E)
    Statistics
    28 recursive calls
    0 db block gets
    24255134 consistent gets
    1891798 physical reads
    0 redo size
    11607488 bytes sent via SQL*Net to client
    544385 bytes received via SQL*Net from client
    14914 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    223681 rows processed
    </pre>

  • Two parallel hints in a merge statement

    I am not sure if using the parallel hint in such a way as below would be helpful in parallelizing the query run. Can a parallel hint be used for two different tables in a merge statement like mentioned below?
    MERGE INTO /*+ parallel (TABLE_A,8) */ TABLE_A  A
    USING( SELECT /*+ parallel (TABLE_B,8) */
                            col1,
                            col2
                  FROM TABLE_B
             )  B
    ON A.col1 = B.col1
    WHEN MATCHED THEN
    UPATE ....
    WHEN NOT MATCHED THEN
    INSERT ...
    I am using Oracle 10g.
    Thanks

    This does make sense (allowing for "someone else"'s observation about aliases); however MERGE is DML, so you couldn't get the merge phase working in parallel if you didn't also execute
    alter session enable parallel dml;
    Regards
    Jonathan Lewis

  • Oracle parallel hint

    Hello,
    Is it possible to set a parallel hint in queries?
    Best regards,
    Andrey

    PARALLEL_MAX_SERVERS is the aggregate limit for all concurrent sessions using Parallelism.  Thus, with your value of 35, you could have 8 sessions using 4 PX slaves each but the 9th session would get three slaves.
    PARALLEL_THREADS_PER_CPU does not need to be changed.  It allows Oracle to determine  PARALLEL_MAX_SERVERS based on CPU_COUNT.
    Similarly, CPU_COUNT is not to be changed.
    For a DML (or a query) you set the Degree based on the the "what is required".  This you would best determine from experience against that particular database.
    A degree of 4 maybe good and sufficient in one environment, for a set of requirements but inadequate in another environment (e.g. number of underlying disks, i/o channels, number of processor cores that are free, concurrent load on the server and storage from other sessions/databases, number of partitions in a target partitioned table) for a different set of requirements (e.g number of rows to be processed, time constraint on the execution).
    Hemant K Chitale

  • Question about PARALLEL hint

    the documentation says that PARALLEL hint can by used in select statements like PARALLEL(emp 8). I have also seen syntaxes like PARALLEL, PARALLEL 8, PARALLEL(8), and in each case the steps in execution plans were the same but the cost assigned was a bit different between each version (but significantly lower than for a query without this hint).
    how does oracle interpret above three syntaxes, ie. /*+ PARALLEL */, /*+ PARALLEL 8 */, /*+ PARALLEL(8) */?
    are there any parts in those syntaxes that are ignored or incorporate default behaviour?
    what syntax is safe to use when one doesn't want to specify the table being parallelized, ie. use syntax like PARALLEL(emp 8)?
    thank you
    Edited by: 943276 on 2012-07-25 19:17

    943276 wrote:
    the documentation says that PARALLEL hint can by used like PARALLEL(emp 8). I have also seen syntaxes like PARALLEL, PARALLEL 8, PARALLEL(8), and in each case the steps in execution plans were the same but the cost assigned was different between each version (and significantly lower than for a query without this hint).
    how does oracle interpret above three syntaxes, ie. /*+ PARALLEL */, /*+ PARALLEL 8 */, /*+ PARALLEL(8) */?
    are there any parts in those syntaxes that are ignored or incorporate default behaviour?
    what syntax is safe to use when one doesn't want to specify the table being parallelized, ie. use syntax like PARALLEL(emp 8)?
    thank you
    Edited by: 943276 on 2012-07-25 19:17You are NOT qualified to use any HINT.
    Oracle recommends against using any HINT.

  • Parallel hint causes a query to run slower?

    I have an insert...select query where the select is a join between a table with one billion rows (although there is a where clause on an indexed column that restricts it to "only" 300 million), a table with 30 million rows, and a table with about 100,000 rows, where the result is about 20 rows. When I first ran it, it took about 2 hours. I added a Parallel hint, and explain plan showed that it was being used (and v$session showed that I had about 30 additional connections while it ran). but not it takes four hours.
    Is there a reason parallel processing would cause a query to run slower?
    insert /*+ append */ into employees_by_age_group
      pay_plan
    , age_range
    , pay_level
    , fy
    , employee_count
    select /*+ parallel */
           emp.pay_plan
         , to_char(d.min_age) || '-' || to_char(d.max_age) as age_range
         , emp.pay_level
         , pay.fy
         , count(pay.employee_id) as employee_count
    from
      select /*+ index(pay_info pay_info_index_on_site) */
             employee_id
           , extract(year from (dte_ppe_end + 92)) as fy
           , count(employee_id) as num_recs
      from pay_info
      where extract(month from dte_ppe_end) = 10
      and   extract(day from dte_ppe_end) between 14 and 27
      and   substr(pay_type, 1, 1) IN ('A', 'B', 'C')
      and   site like 'Z%'
      group by employee_id, extract(year from (dte_ppe_end + 92))
    ) pay
    join
      select employee_id
           , pay_plan
           , pay_grade
           , pay_step
           , file_date
      from
        select /*+ index(employee_info employee_info_index_on_site) */
               employee_id
             , pay_level
             , file_date
             , max(file_date)
               over (partition by extract(year from (file_date + 61)))
               as last_file_date
        from employee_info
        where site like 'Z%'
      where file_date = last_file_date
    ) emp
    on (
         emp.employee_id = pay.employee_id
         and extract(year from emp.file_date) = pay.fy - 1
    join (
           select employee_id
                , dob
           from (
                  select employee_id
                       , date_birth
                       , row_number() over (partition by employee_id order by date_file desc) as r
                  from employee_birthdates
                  where site like 'Z%'
           where r = 1
         ) dob
    on dob.employee_id = pay.employee_id
    join
                select 20 as min_age, 24 as max_age from dual
      union all select 25 as min_age, 29 as max_age from dual
      union all select 30 as min_age, 34 as max_age from dual
      union all select 35 as min_age, 39 as max_age from dual
      union all select 40 as min_age, 44 as max_age from dual
      union all select 45 as min_age, 49 as max_age from dual
      union all select 50 as min_age, 54 as max_age from dual
      union all select 55 as min_age, 59 as max_age from dual
      union all select 60 as min_age, 64 as max_age from dual
      union all select 65 as min_age, 69 as max_age from dual
      union all select 70 as min_age, 74 as max_age from dual
      union all select 75 as min_age, 79 as max_age from dual
      union all select 80 as min_age, 84 as max_age from dual
      union all select 85 as min_age, 89 as max_age from dual
      union all select 90 as min_age, 94 as max_age from dual
      union all select 95 as min_age, 99 as max_age from dual
    ) d
    group by emp.pay_plan, d.min_age, d.max_age, emp.pay_level, pay.fy;

    Paul - here are three different explain plans
    First, the original one (without the parallel hint):
    INSERT STATEMENT  ALL_ROWS                                              Cost: 26,684,255  Bytes: 114  Cardinality: 1                     
      35 LOAD AS SELECT EMPLOYEES_BY_AGE_GROUP                  
        34 HASH GROUP BY                                                    Cost: 26,684,255  Bytes: 114  Cardinality: 1                 
          33 NESTED LOOPS                                                   Cost: 26,684,254  Bytes: 114  Cardinality: 1               
            14 HASH JOIN                                                    Cost: 26,684,222  Bytes: 108  Cardinality: 1             
              9 MERGE JOIN                                                  Cost: 4,408,803  Bytes: 8,322  Cardinality: 146           
                3 VIEW DONBOT_DBA.                                          Cost: 114,863  Bytes: 29,625,180  Cardinality: 987,506         
                  2 WINDOW SORT PUSHED RANK                                 Cost: 114,863  Bytes: 35,550,216  Cardinality: 987,506       
                    1 TABLE ACCESS FULL TABLE EMPLOYEE_BIRTHDATES           Cost: 108,983  Bytes: 35,550,216  Cardinality: 987,506     
                8 SORT JOIN                                                 Cost: 4,293,940  Bytes: 3,645  Cardinality: 135         
                  7 VIEW DONBOT_DBA.                                        Cost: 4,293,939  Bytes: 3,645  Cardinality: 135       
                    6 SORT GROUP BY                                         Cost: 4,293,939  Bytes: 4,185  Cardinality: 135     
                      5 TABLE ACCESS BY INDEX ROWID TABLE PAY_INFO          Cost: 4,293,938  Bytes: 4,185  Cardinality: 135   
                        4 INDEX RANGE SCAN INDEX PAY_INFO_INDEX_ON_SITE     Cost: 487,124  Cardinality: 402,683,034 
              13 VIEW DONBOT_DBA                                            Cost: 22,275,300  Bytes: 1,160,143,257  Cardinality: 22,747,907           
                12 WINDOW SORT                                              Cost: 22,275,300  Bytes: 841,672,559  Cardinality: 22,747,907         
                  11 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO        Cost: 22,137,046  Bytes: 841,672,559  Cardinality: 22,747,907       
                    10 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_INDEX_ON_SITE   Cost: 50,419  Cardinality: 38,019,281     
            32 VIEW DONBOT_DBA
              31 UNION-ALL           
                15 FAST DUAL  Cost: 2  Cardinality: 1         
                16 FAST DUAL  Cost: 2  Cardinality: 1         
                17 FAST DUAL  Cost: 2  Cardinality: 1         
                18 FAST DUAL  Cost: 2  Cardinality: 1         
                19 FAST DUAL  Cost: 2  Cardinality: 1         
                20 FAST DUAL  Cost: 2  Cardinality: 1         
                21 FAST DUAL  Cost: 2  Cardinality: 1         
                22 FAST DUAL  Cost: 2  Cardinality: 1         
                23 FAST DUAL  Cost: 2  Cardinality: 1         
                24 FAST DUAL  Cost: 2  Cardinality: 1         
                25 FAST DUAL  Cost: 2  Cardinality: 1         
                26 FAST DUAL  Cost: 2  Cardinality: 1         
                27 FAST DUAL  Cost: 2  Cardinality: 1         
                28 FAST DUAL  Cost: 2  Cardinality: 1         
                29 FAST DUAL  Cost: 2  Cardinality: 1         
                30 FAST DUAL  Cost: 2  Cardinality: 1          Next, one with the parallel hint:
    INSERT STATEMENT  ALL_ROWS                                                                              Cost: 26,507,111  Bytes: 114  Cardinality: 1                                       
      51 LOAD AS SELECT EMPLOYEES_BY_AGE_GROUP
        50 PX COORDINATOR                                          
          49 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10005 :Q1005                                     Cost: 26,507,111  Bytes: 114  Cardinality: 1                                 
            48 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1005                                           Cost: 26,507,111  Bytes: 114  Cardinality: 1                               
              47 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1005                                            Cost: 26,507,111  Bytes: 114  Cardinality: 1                             
                46 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10004 :Q1004                                    Cost: 26,507,111  Bytes: 114  Cardinality: 1                           
                  45 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1004                                     Cost: 26,507,111  Bytes: 114  Cardinality: 1                         
                    44 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT :Q1004                                    Cost: 26,507,111  Bytes: 114  Cardinality: 1                       
                      25 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1004                                     Cost: 26,507,109  Bytes: 108  Cardinality: 1                     
                        17 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004                                  Cost: 4,301,500  Bytes: 4,104  Cardinality: 72                   
                          16 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10003 :Q1003                          Cost: 4,301,500  Bytes: 4,104  Cardinality: 72                 
                            15 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1003                               Cost: 4,301,500  Bytes: 4,104  Cardinality: 72               
                              7 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1003           
                                6 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1003                           Cost: 4,293,939  Bytes: 1,809  Cardinality: 67           
                                  5 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000                     Cost: 4,293,939  Bytes: 1,809  Cardinality: 67         
                                    4 VIEW DONBOT_DBA.                                                      Cost: 4,293,939  Bytes: 1,809  Cardinality: 67       
                                      3 SORT GROUP BY                                                       Cost: 4,293,939  Bytes: 2,077  Cardinality: 67     
                                        2 TABLE ACCESS BY INDEX ROWID TABLE PAY_INFO                        Cost: 4,293,938  Bytes: 2,077  Cardinality: 67   
                                          1 INDEX RANGE SCAN INDEX PAY_INFO_INDEX_ON_SITE                   Cost: 487,124  Cardinality: 199,756,151 
                              14 VIEW PARALLEL_COMBINED_WITH_PARENT DONBOT_DBA. :Q1003                      Cost: 7,561  Bytes: 29,625,180  Cardinality: 987,506             
                                13 WINDOW SORT PUSHED RANK PARALLEL_COMBINED_WITH_PARENT :Q1003             Cost: 7,561  Bytes: 35,550,216  Cardinality: 987,506           
                                  12 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1003                        Cost: 7,561  Bytes: 35,550,216  Cardinality: 987,506         
                                    11 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 :Q1002                Cost: 7,561  Bytes: 35,550,216  Cardinality: 987,506       
                                      10 WINDOW CHILD PUSHED RANK PARALLEL_COMBINED_WITH_PARENT :Q1002      Cost: 7,561  Bytes: 35,550,216  Cardinality: 987,506     
                                        9 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1002             Cost: 7,557  Bytes: 35,550,216  Cardinality: 987,506   
                                          8 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT EMPLOYEE_BIRTHDATES :Q1002     Cost: 7,557  Bytes: 35,550,216  Cardinality: 987,506 
                        24 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1004                 
                          23 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004                                Cost: 22,205,605  Bytes: 575,504,145  Cardinality: 11,284,395                 
                            22 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10001                               Cost: 22,205,605  Bytes: 575,504,145  Cardinality: 11,284,395               
                              21 VIEW DONBOT_DBA.                                                           Cost: 22,205,605  Bytes: 575,504,145  Cardinality: 11,284,395             
                                20 WINDOW SORT                                                              Cost: 22,205,605  Bytes: 417,522,615  Cardinality: 11,284,395           
                                  19 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO                        Cost: 22,137,046  Bytes: 417,522,615  Cardinality: 11,284,395         
                                    18 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_INDEX_ON_SITE                   Cost: 50,419  Cardinality: 18,859,958       
                      43 VIEW PARALLEL_COMBINED_WITH_PARENT DONBOT_DBA. :Q1004                              Cost: 32  Bytes: 6  Cardinality: 1                     
                        42 UNION-ALL PARALLEL_COMBINED_WITH_PARENT :Q1004                 
                          26 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          27 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          28 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          29 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          30 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          31 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          32 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          33 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          34 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          35 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          36 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          37 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          38 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          39 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          40 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                 
                          41 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2  Cardinality: 1                  Finally, one without the parallel hint, and without the index hint on PAY_TABLE:
    INSERT STATEMENT  ALL_ROWS                                              Cost: 23,348,654  Bytes: 114  Cardinality: 1                   
      34 LOAD AS SELECT ARMYMP.EMPLOYEES_BY_AGE                
        33 HASH GROUP BY                                                    Cost: 23,348,654  Bytes: 114  Cardinality: 1               
          32 NESTED LOOPS                                                   Cost: 23,348,653  Bytes: 114  Cardinality: 1             
            13 HASH JOIN                                                    Cost: 23,348,621  Bytes: 108  Cardinality: 1           
              8 MERGE JOIN                                                  Cost: 1,073,202  Bytes: 8,322  Cardinality: 146         
                3 VIEW DONBOT_DBA.                                          Cost: 114,863  Bytes: 29,625,180  Cardinality: 987,506       
                  2 WINDOW SORT PUSHED RANK                                 Cost: 114,863  Bytes: 35,550,216  Cardinality: 987,506     
                    1 TABLE ACCESS FULL TABLE EMPLOYEE_BIRTHDATES           Cost: 108,983  Bytes: 35,550,216  Cardinality: 987,506   
                7 SORT JOIN                                                 Cost: 958,339  Bytes: 3,645  Cardinality: 135       
                  6 VIEW DONBOT_DBA.                                        Cost: 958,338  Bytes: 3,645  Cardinality: 135     
                    5 SORT GROUP BY                                         Cost: 958,338  Bytes: 4,185  Cardinality: 135   
                      4 TABLE ACCESS FULL TABLE PAY_INFO                    Cost: 958,337  Bytes: 4,185  Cardinality: 135 
              12 VIEW DONBOT_DBA.                                           Cost: 22,275,300  Bytes: 1,160,143,257  Cardinality: 22,747,907         
                11 WINDOW SORT                                              Cost: 22,275,300  Bytes: 841,672,559  Cardinality: 22,747,907       
                  10 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO        Cost: 22,137,046  Bytes: 841,672,559  Cardinality: 22,747,907     
                    9 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_UIC              Cost: 50,419  Cardinality: 38,019,281   
            31 VIEW DONBOT_DBA.                                             Cost: 32  Bytes: 6  Cardinality: 1           
              30 UNION-ALL         
                14 FAST DUAL  Cost: 2  Cardinality: 1       
                15 FAST DUAL  Cost: 2  Cardinality: 1       
                16 FAST DUAL  Cost: 2  Cardinality: 1       
                17 FAST DUAL  Cost: 2  Cardinality: 1       
                18 FAST DUAL  Cost: 2  Cardinality: 1       
                19 FAST DUAL  Cost: 2  Cardinality: 1       
                20 FAST DUAL  Cost: 2  Cardinality: 1       
                21 FAST DUAL  Cost: 2  Cardinality: 1       
                22 FAST DUAL  Cost: 2  Cardinality: 1       
                23 FAST DUAL  Cost: 2  Cardinality: 1       
                24 FAST DUAL  Cost: 2  Cardinality: 1       
                25 FAST DUAL  Cost: 2  Cardinality: 1       
                26 FAST DUAL  Cost: 2  Cardinality: 1       
                27 FAST DUAL  Cost: 2  Cardinality: 1       
                28 FAST DUAL  Cost: 2  Cardinality: 1       
                29 FAST DUAL  Cost: 2  Cardinality: 1        I am surprised the cost without the index is less than the cost with it, considering that it is replacing a Table Access By Index Rowid with a Table Access Full on a table with 1 billion (1000 million) records.
    Igor - two questions:
    One - I cannot find "Materialize" in the hints in the SQL Reference anywhere. What does it do?
    Two - does replacing subqueries with With clauses make that much of a difference?

  • Executing a query with parallel hint

    Hi folks,
    I see a lot of queries executing with parallel hint in our database. Please advice me on couple of questions.
    1. How do i find the all the unix slave process ids associated with a statement executing with parallel hint. For example if a statment has 8 in the parallel hint then it will start 8 parallel process. I need the process ids of those 8 parallel process.
    2. i see a lot of updates on a table and this table is a master table for a snapshot. So the updates are delaying the snapshot refreshes. Is there a way to find out the session id which is making the updates on this table.
    Thanks a lot for your support.
    Karthik

    1. The executing slave processes share the same sql_addr, sql_hash_value, sql_id as the master process in v$session, when they are actively executing.
    2. The sql_text identified by sql_addr, sql_hash_value or prev_sql_addr, prev_hash_value will show you the update statement, when the update is happening or has just happened.

  • SQL query with parallel hint  running very slow

    I have a SQL query which joins three huge tables. (given below)
         insert /*+ append */ into final_table (oid, rmeth, id, expdt, crddt, coupon, bitfields, processed_count)
         select /*+ full(t2) parallel(t2,31) full(t3) parallel(t3,31)*/
         seq_final_table.nextval, '200', t2.id, t3.end_date, '1/jul/2009',123,t2.bitfield, 0
         from table1 t1, table2 t2, table3 t3 where
         t1.id=t2.id and
         t2.pid=t3.pid and
         t2.vid=t3.vid and
         t3.end_date is not null and
         (trunc(t1.expiry_date) != trunc(t3.end_date) or trim(t1.expiry_date) is null);
         Below are some statistics of the three tables.
         Table_Name          RowCount    Size(MB)
         table1 36469938 532
         table2 242172205     39184
         table3 231756758     29814
         The above query ran for 30+ hours, and returned with no rows inserted into final_table. I didn't get any error message also.
         But when I ran the query with table1 containing just 10000 records, the query completed succesfully within 20 minutes.
         Can any one please optimize the above query?
    Edited by: jaysara on Aug 18, 2009 11:51 PM

    As a side note: You probably don't want to insert a string into a date field, won't you?
    Under the assumption that crddt is of datatype date:
    crddt='1/jul/2009' needs to be changed into
    crddt= to_date('01/07/2009','dd/mm/yyyy') This is data type correct and nls independent.

Maybe you are looking for

  • Printing from an iPad to Dymo Label printer 750

    Am i able to print labels from an iPad to a Dymo label printer 750 via a airport express?

  • Opening PDF v1.6 by Acrobat 9

    Hello Friends, Have you ever met with any problems with opening PDF v1.6 (created, supported by Adobe Acrobat standard or professional 7) by Adobe Acrobat standard or professional 9 ? Theoretically appearance of such a problem is very low but maybe s

  • Print debit card

    Hi all,          I am starting with my first smartform and m confused...My requirement is to print a debit card(kind of).They have a preprinted debit card with preprinted back page.I only have to print certain details in the front page which includes

  • Linking ASM to the DB which is yet to be created

    11.2.0.2/AIX 6.1 I have been provided the RMAN Full Cold backup of a single Instance DB. I need to create a RAC DB from this Backup in a new server (actually servers , it is 2 node Grid setup). The Single Instance Source DB name is DEOPC . Instance n

  • Can I log into the App Store in France to buy french apps. I am a uk App Store user

    I would like to be able to install french apps from the French App Store.  Is there a way of doing this?  E.g. I would like an app with French town maps which is free but this seems not to be possible.