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 redlogsHello;
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
AmitI 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:46SO: 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,
JimHello;
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? -
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.
regardsOne 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 - HPHello;
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
AmitHi 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'