Logical standby: SQL Apply too slow

Hi all,
I have a question regarding SQL Apply performance in logical standby. There are two kind of operations that are remarkably slow when applying them on logical standby. These are "truncate table" and "delete from table" operations.
When logical standby pick up one of mentioned statements from logs one of appliers start working whereas rest others are waiting. It looks like standby hang and very slow sql apply is moving on gradually and finally when operation completes standby is behind primary for 4 or 5 or even 8 hours.
What can be done in this regard to speed up sql apply and alleviate this situation?
Best Regards,
Alex

Are you absolutely sure that the truncate is the problem (and deletes). How did you check it?
You can use LogMiner to check what are most of the commands in the log currently applied. I use this:
BEGIN
sys.DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => '/home/oracle/arc_43547_1_595785865.arc', OPTIONS => sys.DBMS_LOGMNR.ADDFILE);
END;
BEGIN
sys.DBMS_LOGMNR.START_LOGMNR( OPTIONS => sys.DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
END;
SELECT seg_owner,seg_name,table_name,operation,COUNT(1) FROM V$LOGMNR_CONTENTS
GROUP BY seg_owner,seg_name,table_name,operation
ORDER BY COUNT(1) DESC
BEGIN
sys.DBMS_LOGMNR.END_LOGMNR();
END;
Most of the times in our cases when SQL Apply is slow is because of high activity on particular object. This can be detected by high number of DMLs for that object using LogMiner. If this object is not needed on the logical standby you can skip it and thus SQL Apply will be faster because it will not apply changes for this particular one. If it's needed and this is not a regular rate, then you can skip it temporarily, turn on SQL Apply , after problematic logs are applied, turn off SQL Apply, instantiate the object and unskip it, turn on sql apply again.
Another thing that can drastically slowdown SQL Apply is the size of memory available for SQL Apply(Alert log shows that max is ~4.5GB or something like this, I'm not sure )
You can increase it with something like this:
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
BEGIN
DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 3000); -- set to 3000 MB
END;
ALTER DATABASE START LOGICAL STANDBY APPLY;
You have to increase it if the following reports:
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE '%page%' OR
NAME LIKE '%uptime%' or name like '%idle%';
that 'bytes paged out' increases if run every few seconds during slow SQL Apply.
I hope that it's something that can be fixed using the above info. If no, please comment and share your investigations.
Thanks

Similar Messages

  • Logical Standby SQL Apply Using Incorrect Decode Statement

    We are seeing statements erroring out on our logical standby that have been rewritten (presumably by sql apply) with decode statements that don't appear to be correct. For example, here is one of the rewritten statements.
    update /*+ streams restrict_all_ref_cons */ "CADPROD"."OMS_SQL_STATEMENT" p
    set *"APPLICATION"=decode(:1,'N',"APPLICATION",:2)*,
    "STATEMENT"=dbms_reputil2.get_final_lob(:3,"STATEMENT",:4)
    where (:5='N' or(1=1 and (:6='N' or(dbms_lob.compare(:7,"STATEMENT")=0)or(:7 is null and "STATEMENT" is null)))) and(:8="APPLICATION")
    The problem comes in, we believe, with the attempt to write the value "APPLICATION" to the application column which is only a 10 character field. the value for the :1 bind variable is "N" and the value for :2 is null.
    We see the following error on the logical standby:
    ORA-00600: internal error code, arguments: [kgh_heap_sizes:ds], [0x01FCDBE60], [], [], [], [], [], []
    ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [kxtoedu+54] [PC:0x2542308] [ADDR:0xFFFFFFFFFFFFFFFF] [UNABLE_TO_READ] []
    ORA-12899: value too large for column "CADPROD"."OMS_SQL_STATEMENT"."APPLICATION" (actual: 19576, maximum: 10)
    Is this a configuration issue or is it normal for SQL Apply to convert statements from logminer into decode statements?
    We have an Oracle 10.2.0.4 database running on windows 2003 R2 64-bit os. We have 3 physical and 2 logical standby's, no problems on the physical standbys.

    Hello;
    I noticed some of your parameters seem to be wrong.
    fal_client - This is Obsolete in 11.2
    You have db_name='test' on the Standby, it should be 'asadmin'
    fal_server=test is set like this on the standby, it should be 'asadmin'
    I might consider changing VALID_FOR to this :
    VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)Would review 4.2 Step-by-Step Instructions for Creating a Logical Standby Database of Oracle Document E10700-02
    Document 278371.1 is showing its age in my humble opinion.
    -----Wait on this until you fix your parameters----------------------
    Try restarting the SQL Apply
    ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATEI don't see the parameter MAX_SERVERS, try setting it to 8 times the number of cores.
    Use these statements to trouble shoot :
    SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;
    SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE ;TRANSACTIONS%';
    SELECT COUNT(1) AS IDLE_PREPARERS FROM V$LOGSTDBY_PROCESS WHERE
    TYPE = 'PREPERER' AND STATUS_CODE = 16166;Best Regards
    mseberg
    Edited by: mseberg on Feb 14, 2012 7:37 AM

  • Logical dataguard SQL apply fails during import on primary database

    I have created logical dataguard using GRID, initially every things works fine.
    One time we had to do import of new data on primary database, that is where the problem started.
    log apply is lagging big time, and i got this error
    StatusRedo apply services stopped due to failed transaction (1,33,8478)
    ReasonORA-16227: DDL skipped due to missing object
    Failed SQLDROP TABLE "USA"."SYS_IMPORT_SCHEMA_01" PURGE
    This table exists on logical dataguard...
    How do we deal with import on logical dataguard, since import generates a lot of redlogs

    Hello;
    These Oracle notes might help :
    Slow Performance In Logical Standby Database Due To Lots Of Activity On Sys.Aud$ [ID 862173.1]
    Oracle10g Data Guard SQL Apply Troubleshooting [ID 312434.1]
    Developer and DBA Tips to Optimize SQL Apply [ID 603361.1]
    Best Regards
    mseberg

  • Logical Standby - Log Apply Error

    Hi All
    I have configured a 10.2.0.4 logical standby database (single instance) for RAC primary by LOG APPLY process stopped with this error:
    ORA-01422: exact fetch returns more than requested number of rows.
    Now I did run this command before creating logical standby: EXECUTE DBMS_LOGSTDBY.BUILD;
    And I know that there are 80 tables which cannot be uniquely identified, which is fine by business.
    Could you someone please tell how can I deal with this problem.
    Regards
    Amit

    I have configured a 10.2.0.4 logical standby database (single instance) for RAC primary by LOG APPLY process stopped with this error:
    ORA-01422: exact fetch returns more than requested number of rows.
    Now I did run this command before creating logical standby: EXECUTE DBMS_LOGSTDBY.BUILD;
    And I know that there are 80 tables which cannot be uniquely identified, which is fine by business.
    Could you someone please tell how can I deal with this problem. It looks like a Bug too, check this below note
    *Bug 5889516 - Intermittently ORA-1422 logical standby errors [ID 5889516.8]*

  • Logic error-hard drive too slow or system overload (new macbook!)

    have made a few short tracks with logic with no probs. when i have tried to play the demo songs which have many tracks, i get an error msg saying hd too slow or system overload. i have a new macbook, 2.4, 2mb ram, 250 gb hd (with loads space left). airport turned off when using logic. what gives???

    Samples that I am using are located on a 7200 external HD.
    Is your external formatted for Mac? If you didn't buy it from a store that sells mac drives specifically, it's probably formatted for windows. You must reformat for Mac or you'll have a lot of performance issues.
    I've a Macbook 2,2 Ghz Core 2 DUO with 2Go of RAM.
    You should get more Ram, it's really cheap these days.
    Airport is disconnected. My AUdio Buffer is 1024 in the Logic preferences.
    Make sure the I/O Safety Buffer is OFF, and then set the buffer size at 256 or 512.

  • Logical Standby Stops Applying Up to a Point 10GR2

    Hi, I'm running a standby on 10.2.0.2
    There are no sequence gaps. I registered all the datafiles so it sees the ones before and after, yet in OEM it shows this:
    Log     Status                                      ResetLogs ID # First Change # (SCN) Last Change # (SCN) Size (KB)
    35334 Committed Transactions Applied 688864038     4819403033                 4819404135               10782
    35335 Partially Applied                         688864038     4819404135                4819404151                92
    35336 Not Applied                                688864038     4819404151                4819404179                87
    Alert log:
    ora-01281 scn range specified is invalid.
    I have tried doing a recover until scn # to no avail.

    Hello;
    I believe i would review and follow this Oracle document:
    (UNREGISTER logfile On Logical Standby (Doc ID 1416433.1))
    Best Regards
    mseberg

  • Recover standby database apply archivelog slow

    1.recover managed standby database disconnect from session;
    2.view alert file,find apply a achivelog last block need 10m
    3.view metalink MAA - Data Guard Redo Apply and Media Recovery Best Practices 10gR1
    modify database parameter,still is slow
    3.view v$managed_standby
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:49:09
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:56
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:57
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:57
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:58
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:58
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:58
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:59
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:59
    SQL>
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:59
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:01
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:01
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:01
    4. dump mrp
    SO: 0xc103c9b58, type: 4, owner: 0xc172b7820, flag: INIT/-/-/0x00
    (session) sid: 1087 trans: (nil), creator: 0xc172b7820, flag: (51) USR/- BSY/-/-/-/-/-
    DID: 0001-0013-00000002, short-term DID: 0000-0000-00000000
    txn branch: (nil)
    oct: 0, prv: 0, sql: (nil), psql: (nil), user: 0/SYS
    service name: SYS$BACKGROUND
    waiting for 'PX Deq: Par Recov Reply' blocking sess=0x(nil) seq=6397 wait_time=0 seconds since wait started=3
    sleeptime/senderid=10010000, passes=19f, =0
    Dumping Session Wait History
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1953964
    sleeptime/senderid=10010000, passes=19e, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954140
    sleeptime/senderid=10010000, passes=19d, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954066
    sleeptime/senderid=10010000, passes=19c, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954065
    sleeptime/senderid=10010000, passes=19b, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954129
    sleeptime/senderid=10010000, passes=19a, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954061
    sleeptime/senderid=10010000, passes=199, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1953991
    sleeptime/senderid=10010000, passes=198, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954123
    sleeptime/senderid=10010000, passes=197, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954120
    sleeptime/senderid=10010000, passes=196, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954073
    sleeptime/senderid=10010000, passes=195, =0
    5.how to read dump process file
    Edited by: 852786 on 2011-4-16 上午1:46

    SO: 0xbf34d65b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4990d0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000001A-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426408, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426418
    SO: 0xbf34d6570, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f499020, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000019-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426380, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426390
    SO: 0xbf34d6530, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498f88, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000018-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174262f8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426308
    SO: 0xbf34d64f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498ef0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000017-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426270, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426280
    SO: 0xbf34d64b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498e58, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000016-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174261e8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174261f8
    SO: 0xbf34d6470, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498dc0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000015-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426160, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426170
    SO: 0xbf34d6430, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498d28, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000014-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174260d8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174260e8
    SO: 0xbf34d63f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498c90, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000013-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426050, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426060
    SO: 0xbf34d63b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498bf8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000012-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425fc8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425fd8
    SO: 0xbf34d6370, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498b60, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000011-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425f40, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425f50
    SO: 0xbf34d6330, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498ac8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000010-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425eb8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425ec8
    SO: 0xbf34d62f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498a30, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000F-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425e30, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425e40
    SO: 0xbf34d62b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498998, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000E-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425da8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425db8
    SO: 0xbf34d6270, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498900, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000D-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425d20, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425d30
    SO: 0xbf34d6230, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498868, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000C-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425c80, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425c90
    SO: 0xbf34d61f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4987d0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000B-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425bf8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425c08
    SO: 0xbf34d61b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498738, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000A-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425b70, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425b80
    SO: 0xbf34d6170, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498688, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000009-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425ae8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425af8
    SO: 0xbf34d6130, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4985f0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000008-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425a60, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425a70
    SO: 0xbf34d60f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498558, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000007-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174259d8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174259e8
    SO: 0xbf34d60b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4984c0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000006-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425950, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425960
    SO: 0xbf34d6070, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498428, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000005-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174258c8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174258d8
    SO: 0xbf34d6030, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498390, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000004-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425840, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425850
    SO: 0xbf34d5ff0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4982f8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000003-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174257b8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174257c8
    SO: 0xbf34d5fb0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498260, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000002-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425730, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425740
    SO: 0xbf34d5f70, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4981c8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000001-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174256a8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174256b8
    SO: 0xc0f498130, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) FS-00000000-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425510, mode: S, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425520
    SO: 0xc0f498000, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000000-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425488, mode: S, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425498
    SO: 0xc13fe20e8, type: 61, owner: 0xc0e403c70, flag: INIT/-/-/0x00
    Process Queue--kxfpq: 0x0xc13fe20e8, serial: 513, # of qrefs: 16,
    inc: 0
    client 2, detached proc: 0x(nil), QC qref 0x(nil), flags: FEML
    Queue Descriptor--kxfpqd: 0x0xc13fe2140, remote queue addr: 0x0xc1
    3fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdd200, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdd200, ser: 513, seq: 1123, err
    or: 0
    opp qref: 0x0xc13fdbb50, process: 0x0xc0e2c33e8, bufs: {0x(nil),
    0x0xb3fe124f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdd310, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdd248, remote queue addr: 0x
    0xc13fdfb40
    instance id: 1, server id: 15, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fe124f8, 0x0xb3fe224f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fe124f8, type: DTA, bufnum: 1
    ser: 513, seq: 1117, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdbb50, from qref: 0x0xc13fdd200, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fe12550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdd410, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdd410, ser: 513, seq: 936, erro
    r: 0
    opp qref: 0x0xc13fdbd60, process: 0x0xc172b8fd8, bufs: {0x(nil),
    0x0xb3fe024f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdd520, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdd458, remote queue addr: 0x
    0xc13fdfd98
    instance id: 1, server id: 14, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fe024f8, 0x0xb3fdf24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fe024f8, type: DTA, bufnum: 1
    ser: 513, seq: 926, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdbd60, from qref: 0x0xc13fdd410, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fe02550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdd620, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdd620, ser: 513, seq: 1076, err
    or: 0
    opp qref: 0x0xc13fdc5a0, process: 0x0xc0f28aa28, bufs: {0x0xb3fd
    d24f8, 0x0xb3fdc24f8}
    state: 10010, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdd730, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdd668, remote queue addr: 0x
    0xc13fdfff0
    instance id: 1, server id: 13, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fdd24f8, 0x0xb3fdc24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fdd24f8, type: DTA, bufnum: 0
    ser: 513, seq: 1069, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdc5a0, from qref: 0x0xc13fdd620, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fdd2550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    Message Buffer--kxfpmh: 0x0xb3fdc24f8, type: DTA, bufnum: 1
    ser: 513, seq: 1076, flags: DIAL, status: RCV, err: 0
    to qref: 0x0xc13fdd620, from qref: 0x0xc13fdc5a0, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fdc2550, remote queue addr:
    0x0xc13fdfff0
    instance id: 1, server id: 13, flags: INIT
    can't dump contents, client unknown
    SO: 0xc13fdda40, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdda40, ser: 513, seq: 1209, err
    or: 0
    opp qref: 0x0xc13fdc7b0, process: 0x0xc102860a8, bufs: {0x(nil),
    0x0xb3fe324f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fddb50, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdda88, remote queue addr: 0x
    0xc13fe0248
    instance id: 1, server id: 12, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fe324f8, 0x0xb3fda24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fe324f8, type: DTA, bufnum: 1
    ser: 513, seq: 1203, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdc7b0, from qref: 0x0xc13fdda40, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fe32550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fddc50, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fddc50, ser: 513, seq: 822, erro
    r: 0
    opp qref: 0x0xc13fdc180, process: 0x0xc0c28be50, bufs: {0x(nil),
    0x0xb3fd924f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fddd60, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fddc98, remote queue addr: 0x
    0xc13fe04a0
    instance id: 1, server id: 11, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fd924f8, 0x0xb3f069230}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fd924f8, type: DTA, bufnum: 1
    ser: 513, seq: 816, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdc180, from qref: 0x0xc13fddc50, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fd92550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdde60, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdde60, ser: 513, seq: 829, erro
    r: 0
    opp qref: 0x0xc13fdbf70, process: 0x0xc0d2a44f8, bufs: {0x(nil),
    0x0xb3f456dc8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fddf70, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fddea8, remote queue addr: 0x
    0xc13fe06f8
    instance id: 1, server id: 10, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3f456dc8, 0x0xb3fd724f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3f456dc8, type: DTA, bufnum: 1
    ser: 513, seq: 823, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdbf70, from qref: 0x0xc13fdde60, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3f456e20, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fde070, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fde070, ser: 513, seq: 1321, err
    or: 0
    opp qref: 0x0xc13fdb940, process: 0x0xc0e2c2c00, bufs: {0x(nil),
    0x0xb3fd424f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fde180, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fde0b8, remote queue addr: 0x
    0xc13fe0950
    instance id: 1, server id: 9, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fd424f8, 0x0xb3f854960}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fd424f8, type: DTA, bufnum: 1
    ser: 513, seq: 1315, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdb940, from qref: 0x0xc13fde070, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fd42550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fde490, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fde490, ser: 513, seq: 1002, err
    or: 0
    opp qref: 0x0xc13fdd830, process: 0x0xc172b87f0, bufs: {0x(nil),
    0x0xb3fde24f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fde5a0, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fde4d8, remote queue addr: 0x
    0xc13fe0ba8
    instance id: 1, server id: 8, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fde24f8, 0x0xb3fd224f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fde24f8, type: DTA, bufnum: 1
    ser: 513, seq: 995, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdd830, from qref: 0x0xc13fde490, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fde2550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fde6a0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fde6a0, ser: 513, seq: 1198, err
    or: 0
    opp qref: 0x0xc13fdcbd0, process: 0x0xc0f28a240, bufs: {0x(nil),
    0x0xb3fd024f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fde7b0, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fde6e8, remote queue addr: 0x
    0xc13fe0e00
    instance id: 1, server id: 7, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fd024f8, 0x0xb3f059230}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fd024f8, type: DTA, bufnum: 1
    ser: 513, seq: 1191, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdcbd0, from qref: 0x0xc13fde6a0, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fd02550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdeac0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdeac0, ser: 513, seq: 1080, err
    or: 0
    opp qref: 0x0xc13fdcde0, process: 0x0xc102858c0, bufs: {0x(nil),
    0x0xb3f436dc8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdebd0, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdeb08, remote queue addr: 0x
    0xc13fe1058
    instance id: 1, server id: 6, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3f436dc8, 0x0xb3fce24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3f436dc8, type: DTA, bufnum: 1
    ser: 513, seq: 1074, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdcde0, from qref: 0x0xc13fdeac0, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3f436e20, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdeee0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdeee0, ser: 513, seq: 1418, err
    or: 0
    opp qref: 0x0xc13fde280, process: 0x0xc0c28b668, bufs: {0x(nil),
    0x0xb3f824960}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdeff0, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdef28, remote queue addr: 0x
    0xc13fe12b0
    instance id: 1, server id: 5, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3f824960, 0x0xb3fcc24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3f824960, type: NUL, bufnum: 1
    ser: 513, seq: 1407, flags: DIAL, status: FRE, err: 0
    to qref: 0x0xc13fdeee0, from qref: 0x0xc13fde280, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3f8249b8, remote queue addr:
    0x0xc13fe12b0
    instance id: 1, server id: 5, flags: INIT
    SO: 0xc13fdf0f0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdf0f0, ser: 513, seq: 949, erro
    r: 0
    opp qref: 0x0xc13fdc390, process: 0x0xc0d2a3d10, bufs: {0x(nil),
    0x0xb3fc924f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdf200, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdf138, remote queue addr: 0x
    0xc13fe1508
    instance id: 1, server id: 4, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fc924f8, 0x0xb3fca24f8}, sta
    te: 10011
    ---------------------------------------

  • Logic Pro: Disk is too slow or system overload (-10009)

    Reoccuring problem while recording in Logic Pro 9.
    (I have the sms disabled and the SSD is far from being 'slow'....)
    Hardware Overview:
      Model Name:          MacBook Pro
      Model Identifier:          MacBookPro5,4
      Processor Name:          Intel Core 2 Duo
      Processor Speed:          2.53 GHz
      Number of Processors:          1
      Total Number of Cores:          2
      L2 Cache:          3 MB
      Memory:          8 GB
      Bus Speed:          1.07 GHz
      Boot ROM Version:          MBP53.00AC.B03
      SMC Version (system):          1.49f2
      Serial Number (system):          W80050EF7XJ
      Hardware UUID:          D33DAD2E-86E3-5F67-BF3B-F546A7169F9F
      Sudden Motion Sensor:
      State:          Disabled
    NVidia MCP79 AHCI:
      Vendor:          NVidia
      Product:          MCP79 AHCI
      Link Speed:          3 Gigabit
      Negotiated Link Speed:          3 Gigabit
      Description:          AHCI Version 1.20 Supported
    OWC Mercury EXTREME Pro SSD:
      Capacity:          240.06 GB (240,057,409,536 bytes)
      Model:          OWC Mercury EXTREME Pro SSD            
      Revision:          361A13F0
      Serial Number:          MXE24011E43F3673   
      Native Command Queuing:          Yes
      Queue Depth:          32
      Removable Media:          No
      Detachable Drive:          No
      BSD Name:          disk0
      Medium Type:          Solid State
      TRIM Support:          Yes
      Partition Map Type:          GPT (GUID Partition Table)
      S.M.A.R.T. status:          Verified
      Volumes:
    disk0s1:
      Capacity:          209.7 MB (209,715,200 bytes)
      BSD Name:          disk0s1
      Content:          EFI
    SSD:
      Capacity:          239.71 GB (239,713,435,648 bytes)
      Available:          118.12 GB (118,116,634,624 bytes)
      Writable:          Yes
      File System:          Journaled HFS+
      BSD Name:          disk0s2
      Mount Point:          /
      Content:          Apple_HFS
    Any help would be appreciated. The troubleshooting sections of the manual and the Power! books dont have an answer. It doesn't appear to be related to the settings and preferences within Logic 9, but I could be wrong.
    Any help is appreciated. If this needs to be asked somewhere just point me in the right direction.
    This only happens during recording. I am using a Focusrite Saffire 6 USB souncard to record if this helps.

    Not a whole lot actually, and I've never tried to record more than one track at a time. I don't seem to have this problem while editing, bouncing. Occasionally I will get an "Out Of Memory!" message. Now, I have 8 gigs of whatever the ****'s in there that was recommended for this laptop, and the 'memory circle' in activity monitor with the red, yellow and blue slices rarely show as being more than half of the green. For instance:
    I haven't been doing alot of recording lately, as I am working to complete David Divorn's advanced logic pro book. (So far) I haven't had any problems with the lessons, all of them editing-based. Though I am also saving all of the project files to the lacie rugged external frewire drive just in case.
    I'm someone who tries to get as much education on the problem. I've used Sonar for 10 years on a PC...and have only been using Logic and a macbook pro since september. I love the SSD otherwise....instant shutdown, 15 second reboot and start-up, apps open fast....I wouldn't know WHY this couldn't handle audio, but I admit I don't know anything about how this stuff works except it blows the PC I had out of the water. All of the issues I had with that are non-existant on this.
    -- I did find a few articles dated over a year or two old that cautioned about using an SSD for audio vs a 7200rpm (conveniently these articles like to present themselves after I've made the purchase and upgrade.

  • Determining the last archive applied on Logical Standby

    Hi,
    I am trying to determine the last log received and applied on my Logical Standby
    SQL> select thread#, max(sequence#) "Last Standby Seq Received"
    from v$archived_log val, v$database vdb
    where val.resetlogs_change# = vdb.resetlogs_change#
    group by thread# order by 1;
       THREAD# Last Standby Seq Received
             1                       14
    SQL> select thread#, max(sequence#) "Last Standby Seq Applied"
    from v$archived_log val, v$database vdb
    where val.resetlogs_change# = vdb.resetlogs_change#
    and applied='YES'
    group by thread# order by 1;
    Does not return anything
    These statements work ok on a physical standby.
    I know Sql Apply is enabled on my logical standby - my broker configuration is enabled and for the logical standby database, it is showing the Intended State as APPLY-ON with no Transport or Apply Lag on any of the databases
    Q. How do I determine the last seq applied on my logical standby ?
    thanks,
    Jim

    Hello;
    I have this from my notes:
    SELECT
      L.SEQUENCE#,
      L.FIRST_TIME,
      (CASE WHEN L.NEXT_CHANGE# < P.READ_SCN THEN 'YES'WHEN L.FIRST_CHANGE# < P.APPLIED_SCN THEN 'CURRENT' ELSE 'NO' END) APPLIED
    FROM
      DBA_LOGSTDBY_LOG L, DBA_LOGSTDBY_PROGRESS P
    ORDER BY SEQUENCE#;
    Best Regards
    mseberg

  • Doubt regarding switchover from logical standby to primary

    I am using Oracle 10g databases on Linux environment
    I was trying creating a data guard configuration and once I was successfully done I created a logical standby database from the physical standby . Then I was trying to do a switchover .
    By mistake I gave the prepare switchover command in the logical standby before executing it in the primary . And then when I gave it in the primary both the status turned to be "PREPARING SWITCHOVER"
    In logical standby
    SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
    Database altered.
    SQL>  SELECT SWITCHOVER_STATUS FROM V$DATABASE;
    SWITCHOVER_STATUS
    PREPARING SWITCHOVER
    In primary
    SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
    Database altered.
    SQL> select switchover_status from v$database;
    SWITCHOVER_STATUS
    PREPARING SWITCHOVERNow I am not able to commit any of them to primary or logical standby
    In primary
    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
    ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY
    ERROR at line 1:
    ORA-16217: prepare to switchover has not completed
    ORA-06512: at line 1
    In logical standby
    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
    ALTER DATABASE commit  TO SWITCHOVER TO PRIMARY
    ERROR at line 1:
    ORA-16109: failed to apply log data from previous primaryLet me know what should be done now ? Is there anyway to solve this issue ?

    Can you try using the following first on Primary and then on Standby?
    ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;

  • Disk is too slow or System Overloaded ERROR

    I have logic studio and a macbook pro and keep getting the following error message:  Logic Pro:  Disk is too slow or System Overloaded (-10010)  Not sure how to fix it.  Any suggestions?

    It's a bug in logic. It's been there since multicore CPUs came out.
    Try putting your fx on a bus/aux rather than on the same track as the instrument.
    That way it will trick logic into using a different core for the different tracks.
    I've seen this problem on dual quad core CPU mac pros, so it has nothing to do with your CPU performance.
    Also if your recording to the internal harddrive whilst playing back audio from it you might run into problems when using bfd2 or addictive drums or any other large sample library type plugin.
    In my MacBook pro I took the DVD drive out and put in an SSD for the OS in its place.
    I then use the internal mechanical drive for recording and samples etc.
    This solved all my issues and made everything so much snappier.
    It's dead easy to do too. Infact it works so well I'm thinking about getting a standard MacBook pro (so I can do the same thing again) instead of the retina one.
    I'd refuse to buy a retina one until I have seen logic play back  1 instance of bfd2 a few audio files whilst at the same time recording a guitar through amplitube 3. I'm not paying £2000 if it can't do that. (you'll be surprised)
    Like I said my old one couldn't do it due to the overloads you mention until I did the DVD drive swap trick.
    The retina looks good but, 1/4" thinner is one thing, but having to carry leads and adapters for everything it kind of defeats the purpose!
    I would need a thunderbolt to FireWire adapter (which aren't out yet) a FireWire 800 lead and a FireWire 800 to 400 adapter jut to plug my apogee duet soundcard in! ***?
    I'd buy a thunderbolt audio interface but their are no mobile ones. The only ones that are out are large ones for the studio (And mac pros don't even have thunderbolt)
    It makes no sense, no sense at all!
    You couldn't make it up. At least they have dropped the dongle from logic so I can plug my mouse in.
    Emagic should release a pc version again. These quarterly decade updates are getting boring!
    Where's logic X?

  • Error message!!!!!Disk is too slow or System Overload this keeps coming up?

    Logic Pro:
    Disk is too slow or System Overload
    (-10010)
    Mac book pro
    10.5.8 OX
    4gigs RAM
    recording to ext 800 firewire drive
    any ideas???

    I am just reposting my response to a similar question because I never found a solution to this problem just a work-around. I would love to know the actual solution.
    I have encountered this issue as well. I never solved the issue but did find a work-around. Unfortunately, this temporary solution may not work for more 'heavy' users then I. Although, many have commented that this issue happens even on small projects (as it did with me also), many usually create much bigger projects and are using the smaller projects just as a litmus test. I qualify this because the work-around I discovered is using USB 2.0 to connect my external HDD rather than either of the firewire ports on the drive. So, for those wanting to create larger projects, this solution may not be an option. I won't delve into the details here, but I will include a link to my thread so you can see all the troubleshooting I did and the suggestions that were offered.
    http://discussions.apple.com/thread.jspa?threadID=2102925&tstart=0
    Or, you can search the forums for error 10010.
    The only other items of note I can think to add at this point is I am still on 10.5.8 not SL. Logic 9.1.1, and I recently increased the amount of RAM to 4G. The work-around has been working for me, and I haven't had time to check that any of these updates fixed the problem. But I will soon and will report any changes.
    I hope this provides some insight.
    Chris

  • Logical Standby Apply became TOO SLOW !!

    Hi,
    I recently have setup a logical standby database. Everything was fine until the apply procedure on the standby became too slow:
    SQL> alter session set nls_date_format = 'HH24:MI:SS (MM/DD)';
    Session altered.
    SQL> SELECT APPLIED_SCN, APPLIED_TIME, READ_SCN, READ_TIME, NEWEST_SCN, NEWEST_TIME FROM DBA_LOGSTDBY_PROGRESS;
    APPLIED_SCN APPLIED_TIME READ_SCN READ_TIME NEWEST_SCN
    NEWEST_TIME
    3036960310 18:33:28 (05/31) 3035938077 18:12:43 (05/31) 3060387972
    16:30:16 (06/02)
    SQL>
    The applied time changed about 20 minutes during last 46 hours. v$logstdby says:
    COORDINATOR: ORA-16116: no work available
    READER, BUILDER and PREPARER: ORA-16127: stalled waiting for additional transactions to be applied
    All APPLIERs: ORA-16116: no work available
    I really don't have any idea about this issue. Any help will be appreciated.
    regards

    One reason could be the SQL Apply engine performs too many slow full table scans, check metalink note:
    Determining if SQL Apply Engine is Performing Full Table Scans
    Doc ID: Note:255958.1
    If this is the reason for the slowness you have to tune your DML statements.
    Werner

  • SQL apply is very slow on Logical Standby..!!

    Hello all,
    We are having Data Guard setup in our environment where we are having Primary, Physical Standby as well as logical standby databases..
    DB Version : 10.2.0.1 in all databases (Pri, Phy and Logical)
    OS : RHEL4
    Only Oracle is running on this Box..
    Since last month we are facing problems in Logical Standby database where it seems SQL apply has become very slow..
    Archive log files are successfully transferring from Primary but since SQL apply has become slow logical standby is lagging behind primary by two days..
    How do i speed up this SQL apply..?? Any ideas and suggestions are most welcome..
    I checked TOP command to find out which oracle processes are consuming maximum CPU and i have found ora_p000_oracle, ora_p001_oracle, ora_p002_oracle, ora_p003_oracle, ora_p004_oracle, ora_p005_oracle, etc processes are consuming highest CPU and Load Average has always been above 1..
    Any help would be greatly appreciated..
    Thanks - HP

    Hello;
    These Oracle notes might help :
    Slow Performance In Logical Standby Database Due To Lots Of Activity On Sys.Aud$ [ID 862173.1]
    Oracle10g Data Guard SQL Apply Troubleshooting [ID 312434.1]
    Developer and DBA Tips to Optimize SQL Apply [ID 603361.1]
    Best Regards
    mseberg

  • Slow SQL Apply on Logical Standby Database in Oracle10g

    Hi,
    We are using Oracle 10g Logical Standby database in our production farm but whenever there is bulk data load (5-6 GB data) on the primary database, the logical standby seems to be hung. It takes days to apply the 5-6 GB data on the logical standby.
    Can anybody give me some pointers how can I make my SQL Apply fast on the logical standby for bulk data.
    Thanks
    Amit

    Hi there,
    I've a similar problem. I did an insert of 700k on a table. It takes me over 1 1/2 hours to see the data. Notice, I increased the "max_sga" to 300m and "max_servers" to 25" and didn't help the performance at all.
    My version is 10.2.0.3 with the patch 6081550.
    APPLIED_SCN APPLIED_TIME RESTART_SCN RESTART_TIME LATEST_SCN LATEST_TIME MINING_SCN MINING_TIME
    1015618 29-NOV-2007 18:28:51 1009600 29-NOV-2007 18:28:51 1017519 29-NOV-2007 19:54:07 1015656 29-NOV-2007 18:32:14

Maybe you are looking for

  • Problem in loading large data to SDE using Shp2sde command

    Hi, When we try load data to SDE (Oracle 8.1.5, Sun solaris 2.6)using shp2sde command, we get the following error message and the data is loaded partially:- " SDE: Shape #2560 is an invalid entity type for layer station. 3337 features converted 3337

  • Custom seach help for standard field in Web dynpro application

    Hi All, I have a requirement in SRM portal where in I have a to add a custom search help to the 'WBS_ELEMENT' field in the the 'ACCOUNT ASSIGNMENT' tab of the Shopping cart creation screen with some input parameters on the search help. As the SRM Sho

  • Custom Deserialization for a List of serializable objects

    I'm running into trouble creating custom deserialization using the readObject method. Here is the code the reads the blob from the database: Blob blob = rs.getBlob(idx++);             InputStream iStream = blob.getBinaryStream();             try {   

  • Select top 10 in pivot special...

    How can I get the top 10 customers in the selected period. Group only customer. Then use these 10 customers and list them in each month, regardless what value they have on each month. The total value in the hole period should decide that. Group Year_

  • TO_Number Function showing wrong values

    Hi All,           I am passing a Char value from oracle forms to oracle reports as parameter. In Report Query I'm converting the char value into number for comparison using TO_NUMBER() function. As the char value is large value like '001002004006004'