Gv$global_transaction locked in crash(?) recovery

Hello,
my first post on this public forum :)
We are facing some system slowdown (or hang) due to locks on either (sometimes both) gv$global_transaction or dba_pending_transactions view. Browsing the session during
"hangs" we find up to 64 parallel processes recovering (presumably dead) transactions.
So far so good: we have 16 cpus * 4 (fast_start_parallel_rollback set to high).
I thought that FSPR param is relevant only for crash recovery (is that right?) so we drilled
down the problem discovering that during these "hangs" one of the nodes N1 can't feel
N2 whilst It's true the opposite (N2 feels N1).
I can't explain the lock, to be more specific: enqueues. Is the parallel activities that
actually locks the segment underlying the views?
Why the parallel activity?
either Oracle uses FSPR for any kind of rollback activity (not only for crash recovery)
or Oracle uses FSPR also for distributed trans
or Oracle uses FSPR when rb activity is estimated above a certain threshold
or in my case N1 thought N2 is down and took over N2's transaction recovery
Machines are 2 x (9.2.0.8/64 RAC on Solaris 9/64)
Thank for your patience
g

Similar Messages

HT1212 my iphone is locked in iphone recovery mode after I restored it and now I get an unknown error (3004)

my iphone is locked in iphone recovery mode after I restored it and now I get an unknown error (3004)

http://support.apple.com/kb/TS3694#communication

When occurs crash recovery,why use active online redo log not archived log?

If current redo log had archived, but it's still 'ACTIVE'. As we all know, archived log is just an archived copy of the current redo log which is still 'ACTIVE', they have the same data. But why use active online redo log not archived log for crash recovery?(I think, if crash recovery can use archived log, then whether the online redo log is 'ACTIVE' or not, it can be overwritten)
Quote:
Re: v$log : How redo log file can have a status ACTIVE and be already archived?
Hemant K Chitale
If your instance crashes, Oracle attempts Instance Recovery -- reading from the Online Redo Logs. It doesn't need ArchiveLogs for Instance Recovery.
TanelPoder
Whether the log is already archived or not doesn't matter here, when the instance crashes, Oracle needs some blocks from that redolog. Archivelog is just an archived copy of the redolog, so you could use either the online or achive log for the recovery, it's the same data in there (Oracle reads the log/archivelog file header when it tries to use it for recovery and validates whether it contains the changes (RBA range) in it what it needs).

Aman.... wrote:
John,
Are you sure that the instance recovery (not the media recovery) would be using the archived redo logs? Since the only thing that would be lost is the isntance, there wouldn't be any archived redo log generated from the Current redo log and the previous archived redo logs, would be already checkpointed to the data file, IMHO archived redo logs won't participate in the instance recovery process. Yep, shall watch the video but tomorrow .
Regards
Aman....
That's what I said. Or meant to say. If Oracle used archivelogs for instance recovery, it would not be possible to recover in noarchive log mode. So recovery relies exclusively on the online log.
Sorry I wasted your time, I'll try to be less ambiguous in future

Crash recovery of productive db very slow

We had to shutdown a productive database with db2_kill, because it couldn't be stopped normally and had problem with a full FAILARCHPATH (After TSM server had problems, the archiving to TSM has not been successfully any more, even after TSM Server was up again: We had this problems before....)
The crash recovery takes very long. Sometimes even db2 list utilities <show details> seems to hang.
With db2pd -everything I can see the progress of the crash recovery:
Database Partition 0 -- Database PC1 -- Active -- Up 0 days 01:57:14 -- Date 05/07/2008 11:34:59
Recovery:
Recovery Status     0x00000C01
Current Log         S0003363.LOG
Current LSN         061F2B330DBA
Job Type            CRASH RECOVERY
Job ID              1
Job Start Time      (1210145904) Wed May 7 09:38:24 2008
Job Description     Crash Recovery
Invoker Type        User
Total Phases        2
Current Phase       1
Progress:
Address            PhaseNum   Description          StartTime                  CompletedWork                TotalWork
0x000000020018E580 1          Forward              Wed May 7 09:38:24 2008   786766439 bytes              1998253346 bytes
0x000000020018E670 2          Backward             NotStarted                 0 bytes                      1998253346 bytes
So the db has now finished approx 1/3 of the bytes of the forward phase and then also have the backward phase!
In the db2diag.log there are no more entries after beginning of the crash recovery of 09:38.
We have move one logfile from the FAILARCHPATH directory (which was 100% full) to a different directory to be sure, that the slow crash recovery has nothing to do with the full FAILARCHPATH.
The log_dir directory has 20 logfiles (LOGPRIMARY+ LOGSECOND) in it (more could not be allocated there because the log_dir is sized according to the LOG-Parameters)
Parameter UTIL_HEAP_SZ = 150.000
Does anybody have an idea, why the crash recovery is so slow ?
Kind regards,
Uta

Hello Ralph,
the needed logfiles were all there and we didn't need to restore any logfiles from tsm (the "active" logfiles, which are needed for crash recovery should always reside in the log_dir...)
At 2008-05-07-14.17.07.357544   crash recovery was completed successfully.
At 2008-05-07-13.56.41.297552   the db has started archiving to tsm again:
ADM1844I Started archive for log file "S0003329.LOG".
According to dba collegues the crash recovery were only 50 % finished and then suddenly everything was finished. Since the "db2 list utilities" takes forward and backward phase into account for percentage, I assume that the backward phase was very fast.
The dba collegues have also recognized, that in the log_dir there were logfiles which were archived to tsm already. So they moved them out of the log_dir, and additional logfiles could be allocated (Before no add. logfile could be allocated). I couldn't say, if this was the reason, why the recovery was finished then afterwards.
The only problem is, that the database doesn't want to archive Logfiles S0003329- S0003350. Strange is also, that logfile 3329 was archived to the FAILARCHPATH yesterday successfully,
2008-05-06-12.27.10.316403+120 E4284459A420       LEVEL: Warning
PID     : 3907                 TID : 1           PROC : db2logmgr (PC1) 0
INSTANCE: db2pc1               NODE : 000
FUNCTION: DB2 UDB, data protection, sqlpgArchiveLogFile, probe:3170
MESSAGE : ADM1846I Completed archive for log file "S0003329.LOG" to
          "/db2/PC1/log_archive/db2pc1/PC1/NODE0000/C0000009/" from
          "/db2/PC1/log_dir/".
and now the db searches in the log_dir:
2008-05-07-13.57.02.525715+120 E25224816A315      LEVEL: Warning
PID     : 28182                TID : 1           PROC : db2logmgr (PC1) 0
INSTANCE: db2pc1               NODE : 000
FUNCTION: DB2 UDB, data protection, sqlpgArchiveLogFile, probe:3108
MESSAGE : ADM1844I Started archive for log file "S0003329.LOG".
2008-05-07-13.57.02.526949+120 I25225132A364      LEVEL: Error
PID     : 28182                TID : 1           PROC : db2logmgr (PC1) 0
INSTANCE: db2pc1               NODE : 000
FUNCTION: DB2 UDB, data protection, sqlpgArchiveLogVendor, probe:1630
RETCODE : ZRC=0x860F000A=-2045837302=SQLO_FNEX "File not found."
          DIA8411C A file "" could not be found.
2008-05-07-13.57.02.527866+120 E25225497A367      LEVEL: Warning
PID     : 28182                TID : 1           PROC : db2logmgr (PC1) 0
INSTANCE: db2pc1               NODE : 000
FUNCTION: DB2 UDB, data protection, sqlpgArchiveLogFile, probe:3150
MESSAGE : ADM1848W Failed archive for log file "S0003329.LOG" to "TSM chain 9"
2008-05-07-13.57.02.528352+120 I25225865A370      LEVEL: Error
PID     : 28182                TID : 1           PROC : db2logmgr (PC1) 0
INSTANCE: db2pc1               NODE : 000
FUNCTION: DB2 UDB, data protection, sqlpgArchiveLogFile, probe:3160
MESSAGE : Failed to archive log file S0003329.LOG to TSM chain 9 from
          /db2/PC1/log_dir/ with rc = -2045837302.
and this was none of the logfiles, which the collegue moved out of log_dir.
Has anybody seen the situation that the db couldn't archive from failarchpath to TSM after failure. We don't want to control every FAILARCHPATH after TSM-Failures....
Kind regards,
Uta

Aborting crash recovery due to error 354

Help, What do I do?
alter database open
Mon Jun 16 06:47:10 2008
Beginning crash recovery of 1 threads
Mon Jun 16 06:47:10 2008
Started redo scan
Mon Jun 16 06:47:34 2008
Errors in file c:\oraclexe\app\oracle\admin\xe\udump\xe_ora_3496.trc:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 18350 change 56285546348545 time 06/04/2008 13:42:02
ORA-00334: archived log: 'C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_2R411073_.LOG'
Mon Jun 16 06:47:34 2008
Aborting crash recovery due to error 354
Mon Jun 16 06:47:34 2008
Errors in file c:\oraclexe\app\oracle\admin\xe\udump\xe_ora_3496.trc:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 18350 change 56285546348545 time 06/04/2008 13:42:02
ORA-00312: online log 2 thread 1: 'C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_2R411073_.LOG'
ORA-354 signalled during: alter database open...
Mon Jun 16 07:09:38 2008
db_recovery_file_dest_size of 10240 MB is 0.98% used.

You are certified but you don't know how to to recover a database with corrupt redo logs? There you have my problem with certificates: they don't tell you jack about the true knowledge of the DBA and his problem solving skills. (or is this exactly what you are saying with "book knowledge"? I am no native English speaker, so I might have misunderstood).
Just enter your ORA-error in a metalink search and you will find notes that explain exactly what to do (the how-to's you mention ;))

Crash recovery: recreating invalid indexes

I want to discuss a phaenomen, which we often have saw during crash recoveries:
The "startsap db" is hanging, because after the crash recocvery itself is completed (according to db2diag.log), the connection to the database ist still hanging because the database recreate invalid indexes.
sf503:db2p02 10% db2 list utilities
ID                               = 2
Type                             = RESTART RECREATE INDEX
Database Name                    = P02
Partition Number                 = 0
Description                      = Recreating Invalid Index Objects
Start Time                       = 05/08/2007 09:37:42.721072
Sometimes this can take up to 25 minutes until this is finished and the connect is finished.
The strange thing is:
If a 2. connection to the database is made during "recreating indexes", this 2. connection is successfull and selects from t000 are successfull.
So, it is possible to execute "startsap r3" while the first connection is still blocked with recreating indexes.
I don't understand this behaviour:
- If the database really needs the recreation of invalid index objects for sucessfull database operation, then it should block ALL connections and not only the first one.
- If it's not urgently necessary, the database should done the recreating indexes in background and not block the first connection.
Also in the Recovery& High Availibility IBM Handbook I have nothing found about the "recreating invalid index objects"-feature.
Kind regards
Uta

Hello Jens,
thanks for the detailed answer!
As you wrote, the only workarond with changing db cfg parameter from "restart" to "access" needs some manual intervention if we don't want to risk the limit of maximum dialog runtime. So actually we will leave it as it is. We have a workaround with starting sap in a second window, when the crash recovery is finished according to db2diag.log and the 1. connection (startsap db) ist still recreating invalid indexes.
How can one determine the invalid indexes, who need recreation ?
Joachim: we don't have a real problem at our site. Fortunatelly we have crash recoveries only in the rare cases of system crashes, etc. So we are lucky not to have it every day....
Hopefully the behaviour will be changed to background index recreation in some later DB release.

"cache recovery" vs "crash recovery" ?

Dear Friends ,
Would anybody plz tell me the difference between "cache recovery" and "crash recovery" in oracle ?
I search in google but dont get satisfactory answer ... ...

shipon_97 wrote:
Dear Friends ,
Would anybody plz tell me the difference between "cache recovery" and "crash recovery" in oracle ?
I search in google but dont get satisfactory answer ... ...Crash recovery is performed whenever their is instance failure (single instance or RAC)
Crash recovery is done in two phase 1) Cache recovery 2) Transaction Recovery.
So crash recovery includes cache recovery.
Cache recovery means to apply redo log from log cache to the datafiles which may contain uncommitted transaction also.
These uncommitted transactions should be rolled back during crash recovery, and hence in transaction recovery it applied undo for all such uncommitted transaction.
Regards
Anurag

Crash recovery

Hello,
Who initiate the crash recovery? SMON process or any other process?
In the ealier version of oracle (Oracle 7.3), it was instance recovery,
Now in Oracle 9i there are two types of recovery one crash recovery and another is instance recovery.
I want to know that whether in prior to Oracle 9i, there were two such recovery or only one?
Thanks.

crash recovery
The automatic application of online redo records to a database after either a single-instance database crashes or all instances of an Oracle Real Applications Cluster configuration crash. Crash recovery only requires redo from the online logs: archived redo logs are not required.
In crash recovery, an instance automatically recovers the database before opening it. In general, the first instance to open the database after a crash or SHUTDOWN ABORT automatically performs crash recovery.
instance recovery
In an Oracle Real Applications Cluster configuration, the application of redo data to an open database by an instance when this instance discovers that another instance has crashed.
Hope it helps.
http://download.oracle.com/docs/cd/B10501_01/server.920/a96519/glossary.htm#432431
Adith

Crash recovery everytime starting an instance

Is it normal that a crash recovery is started every time I start
an Oracle instance on a WinNT 4.0 system.
The xxxALRT.log file contains messages like this:
alter database open
Beginning crash recovery of 1 threads
Thread recovery: start rolling forward thread 1
and so on ...
The database startup takes a long time but after that the db
works normal.

Oracle always does recovery processing on startup. If you
shutdown abort your startup will take longer because there is
more recovery processing that has to be done. Shutting down
immediate takes longer because it performs clean up process so
that when you startup not as much recovery processing is needed.

Crash recovery/ instance recovery

Hi,
How do oracle identifies crash recovery/ instance recovery
is required?
Regards,
Mathew

Hi,
>>But how do oracle identifies dabase is abnormally down and crash recovery is required?
I think that the checkpoint information that is desynchronized in redo log files and datafiles. It is necessary understand what is a checkpoint and what the CKPT process do. A checkpoint is a moment in time when all the changes (dirty blocks) made in the database buffer cache are made to the data files. The checkpoint is performed by the CKPT process and it creates an entry in the control file to identify the point in the online redo log file from where the instance recovery should begin in case of an instance failure. One of the ways a checkpoint is initiated is by the data block writer (DBWR) process. The DBWR process initiates a checkpoint by writing all modified data blocks in the data buffers (dirty buffers) to the data files. After a checkpoint is performed, all committed transactions are written to the data files. If the instance were to crash at this point, only new transactions that occurred after this checkpoint would need to be applied to the database to enable a complete recovery. Therefore, the checkpoint process determines which transactions from the redo logs need to be applied to the database in the event of a failure and subsequent recovery.
Cheers

"Beginning crash recovery of 1 threads"

Hi there!
Can you please inform if this is a problem? I'm getting "Beginning crash recovery of 1 threads" on every database startup (alert.log)
Thanks

Here is my alert log from a few days:
Sun May 30 00:01:31 2010
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows NT Version V6.0 Service Pack 2
CPU                 : 8 - type 8664, 8 Physical Cores
Process Affinity    : 0x0000000000000000
Memory (Avail/Total): Ph:17900M/20477M, Ph+PgF:36037M/37825M
Sun May 30 00:01:31 2010
Starting ORACLE instance (restrict)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters with non-default values:
processes                = 150
__shared_pool_size       = 1526726656
__large_pool_size        = 0
__java_pool_size         = 16777216
__streams_pool_size      = 0
nls_language             = AMERICAN
nls_territory            = AMERICA
sga_target               = 10737418240
control_files            = E:\ORADATA\MYDB\CONTROL01.CTL, F:\ORADATA\MYDB\CONTROL02.CTL, H:\ORADATA\MYDB\CONTROL03.CTL
db_block_size            = 8192
__db_cache_size          = 9177137152
compatible               = 10.2.0.3.0
log_archive_dest_1       = LOCATION=g:\archives\MYDB
log_archive_format       = ARC%S_%R.%T
db_file_multiblock_read_count= 16
undo_management          = AUTO
undo_tablespace          = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain                =
dispatchers              = (PROTOCOL=TCP) (SERVICE=MYDBXDB)
local_listener           = (ADDRESS=(PROTOCOL=TCP)(HOST=192.2.6.154)(PORT=1521))
remote_dependencies_mode = SIGNATURE
job_queue_processes      = 10
audit_file_dest          = H:\ADMIN\MYDB\ADUMP
background_dump_dest     = H:\ADMIN\MYDB\BDUMP
user_dump_dest           = H:\ADMIN\MYDB\UDUMP
core_dump_dest           = H:\ADMIN\MYDB\CDUMP
db_name                  = MYDB
open_cursors             = 300
pga_aggregate_target     = 1073741824
PMON started with pid=2, OS id=1808
PSP0 started with pid=3, OS id=4848
MMAN started with pid=4, OS id=4824
DBW0 started with pid=5, OS id=4604
LGWR started with pid=6, OS id=776
CKPT started with pid=7, OS id=2012
SMON started with pid=8, OS id=4404
RECO started with pid=9, OS id=4484
CJQ0 started with pid=10, OS id=4396
MMON started with pid=11, OS id=5088
Sun May 30 00:01:31 2010
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=4552
Sun May 30 00:01:31 2010
starting up 1 shared server(s) ...
Oracle Data Guard is not available in this edition of Oracle.
Sun May 30 00:01:31 2010
alter database "MYDB" mount exclusive
Sun May 30 00:01:35 2010
Setting recovery target incarnation to 2
Sun May 30 00:01:36 2010
Successful mount of redo thread 1, with mount id 4241184411
Sun May 30 00:01:36 2010
Database mounted in Exclusive Mode
Completed: alter database "MYDB" mount exclusive
Sun May 30 00:01:36 2010
alter database open
Sun May 30 00:01:37 2010
Beginning crash recovery of 1 threads
Sun May 30 00:01:37 2010
Started redo scan
Sun May 30 00:01:37 2010
Completed redo scan
895 redo blocks read, 112 data blocks need recovery
Sun May 30 00:01:37 2010
Started redo application at
Thread 1: logseq 8835, block 70913
Sun May 30 00:01:37 2010
Recovery of Online Redo Log: Thread 1 Group 3 Seq 8835 Reading mem 0
Mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Sun May 30 00:01:37 2010
Completed redo application
Sun May 30 00:01:37 2010
Completed crash recovery at
Thread 1: logseq 8835, block 71808, scn 282384241
112 data blocks read, 112 data blocks written, 895 redo blocks read
Sun May 30 00:01:37 2010
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=16, OS id=1780
Sun May 30 00:01:37 2010
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started with pid=17, OS id=2524
Sun May 30 00:01:37 2010
Thread 1 advanced to log sequence 8836 (thread open)
Thread 1 opened at log sequence 8836
Current log# 1 seq# 8836 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Successful open of redo thread 1
Sun May 30 00:01:37 2010
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
Sun May 30 00:01:37 2010
ARC1: Becoming the heartbeat ARCH
Sun May 30 00:01:37 2010
SMON: enabling cache recovery
Sun May 30 00:01:39 2010
Successfully onlined Undo Tablespace 1.
Sun May 30 00:01:39 2010
SMON: enabling tx recovery
Sun May 30 00:01:39 2010
Database Characterset is WE8ISO8859P1
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=18, OS id=4716
Sun May 30 00:01:42 2010
Completed: alter database open
Sun May 30 00:01:43 2010
ALTER SYSTEM disable restricted session;
Sun May 30 00:07:39 2010
Thread 1 advanced to log sequence 8837 (LGWR switch)
Current log# 2 seq# 8837 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Sun May 30 00:10:27 2010
Thread 1 advanced to log sequence 8838 (LGWR switch)
Current log# 3 seq# 8838 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Sun May 30 00:11:25 2010
Thread 1 advanced to log sequence 8839 (LGWR switch)
Current log# 1 seq# 8839 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Sun May 30 00:12:30 2010
Thread 1 advanced to log sequence 8840 (LGWR switch)
Current log# 2 seq# 8840 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Sun May 30 00:17:07 2010
Thread 1 advanced to log sequence 8841 (LGWR switch)
Current log# 3 seq# 8841 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Sun May 30 00:21:15 2010
Thread 1 advanced to log sequence 8842 (LGWR switch)
Current log# 1 seq# 8842 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Sun May 30 00:22:31 2010
Thread 1 advanced to log sequence 8843 (LGWR switch)
Current log# 2 seq# 8843 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Sun May 30 00:23:44 2010
Thread 1 advanced to log sequence 8844 (LGWR switch)
Current log# 3 seq# 8844 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Sun May 30 00:26:44 2010
Thread 1 advanced to log sequence 8845 (LGWR switch)
Current log# 1 seq# 8845 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Sun May 30 00:27:51 2010
Thread 1 advanced to log sequence 8846 (LGWR switch)
Current log# 2 seq# 8846 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Sun May 30 00:30:51 2010
Thread 1 advanced to log sequence 8847 (LGWR switch)
Current log# 3 seq# 8847 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Sun May 30 01:01:42 2010
Thread 1 advanced to log sequence 8848 (LGWR switch)
Current log# 1 seq# 8848 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Sun May 30 01:01:58 2010
Thread 1 advanced to log sequence 8849 (LGWR switch)
Current log# 2 seq# 8849 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Sun May 30 01:02:13 2010
Thread 1 advanced to log sequence 8850 (LGWR switch)
Current log# 3 seq# 8850 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Sun May 30 01:02:29 2010
Thread 1 advanced to log sequence 8851 (LGWR switch)
Current log# 1 seq# 8851 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Sun May 30 01:02:44 2010
Thread 1 advanced to log sequence 8852 (LGWR switch)
Current log# 2 seq# 8852 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Sun May 30 01:02:54 2010
Thread 1 advanced to log sequence 8853 (LGWR switch)
Current log# 3 seq# 8853 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Sun May 30 13:00:58 2010
Thread 1 advanced to log sequence 8854 (LGWR switch)
Current log# 1 seq# 8854 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Dump file h:\admin\MYDB\bdump\alert_MYDB.log
Mon May 31 00:00:33 2010
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows NT Version V6.0 Service Pack 2
CPU                 : 8 - type 8664, 8 Physical Cores
Process Affinity    : 0x0000000000000000
Memory (Avail/Total): Ph:18101M/20477M, Ph+PgF:35984M/37825M
Mon May 31 00:00:33 2010
Starting ORACLE instance (restrict)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters with non-default values:
processes                = 150
__shared_pool_size       = 1526726656
__large_pool_size        = 0
__java_pool_size         = 16777216
__streams_pool_size      = 0
nls_language             = AMERICAN
nls_territory            = AMERICA
sga_target               = 10737418240
control_files            = E:\ORADATA\MYDB\CONTROL01.CTL, F:\ORADATA\MYDB\CONTROL02.CTL, H:\ORADATA\MYDB\CONTROL03.CTL
db_block_size            = 8192
__db_cache_size          = 9177137152
compatible               = 10.2.0.3.0
log_archive_dest_1       = LOCATION=g:\archives\MYDB
log_archive_format       = ARC%S_%R.%T
db_file_multiblock_read_count= 16
undo_management          = AUTO
undo_tablespace          = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain                =
dispatchers              = (PROTOCOL=TCP) (SERVICE=MYDBXDB)
local_listener           = (ADDRESS=(PROTOCOL=TCP)(HOST=192.2.6.154)(PORT=1521))
remote_dependencies_mode = SIGNATURE
job_queue_processes      = 10
audit_file_dest          = H:\ADMIN\MYDB\ADUMP
background_dump_dest     = H:\ADMIN\MYDB\BDUMP
user_dump_dest           = H:\ADMIN\MYDB\UDUMP
core_dump_dest           = H:\ADMIN\MYDB\CDUMP
db_name                  = MYDB
open_cursors             = 300
pga_aggregate_target     = 1073741824
PMON started with pid=2, OS id=1068
PSP0 started with pid=3, OS id=4512
MMAN started with pid=4, OS id=4452
DBW0 started with pid=5, OS id=784
LGWR started with pid=6, OS id=4608
CKPT started with pid=7, OS id=4524
SMON started with pid=8, OS id=1976
RECO started with pid=9, OS id=3808
CJQ0 started with pid=10, OS id=4056
MMON started with pid=11, OS id=4792
Mon May 31 00:00:33 2010
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=4208
Mon May 31 00:00:33 2010
starting up 1 shared server(s) ...
Oracle Data Guard is not available in this edition of Oracle.
Mon May 31 00:00:33 2010
alter database "MYDB" mount exclusive
Mon May 31 00:00:37 2010
Setting recovery target incarnation to 2
Mon May 31 00:00:37 2010
Successful mount of redo thread 1, with mount id 4241228001
Mon May 31 00:00:37 2010
Database mounted in Exclusive Mode
Completed: alter database "MYDB" mount exclusive
Mon May 31 00:00:37 2010
alter database open
Mon May 31 00:00:38 2010
Beginning crash recovery of 1 threads
Mon May 31 00:00:38 2010
Started redo scan
Mon May 31 00:00:38 2010
Completed redo scan
815 redo blocks read, 108 data blocks need recovery
Mon May 31 00:00:38 2010
Started redo application at
Thread 1: logseq 8854, block 31079
Mon May 31 00:00:38 2010
Recovery of Online Redo Log: Thread 1 Group 1 Seq 8854 Reading mem 0
Mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 00:00:38 2010
Completed redo application
Mon May 31 00:00:38 2010
Completed crash recovery at
Thread 1: logseq 8854, block 31894, scn 282601383
108 data blocks read, 108 data blocks written, 815 redo blocks read
Mon May 31 00:00:38 2010
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=16, OS id=1792
Mon May 31 00:00:38 2010
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started with pid=17, OS id=5048
Mon May 31 00:00:38 2010
Thread 1 advanced to log sequence 8855 (thread open)
Thread 1 opened at log sequence 8855
Current log# 2 seq# 8855 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Successful open of redo thread 1
Mon May 31 00:00:38 2010
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
Mon May 31 00:00:38 2010
ARC0: Becoming the heartbeat ARCH
Mon May 31 00:00:38 2010
SMON: enabling cache recovery
Mon May 31 00:00:40 2010
Successfully onlined Undo Tablespace 1.
Mon May 31 00:00:40 2010
SMON: enabling tx recovery
Mon May 31 00:00:40 2010
Database Characterset is WE8ISO8859P1
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=18, OS id=4612
Mon May 31 00:00:42 2010
Completed: alter database open
Mon May 31 00:00:42 2010
ALTER SYSTEM disable restricted session;
Mon May 31 00:06:45 2010
Thread 1 advanced to log sequence 8856 (LGWR switch)
Current log# 3 seq# 8856 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Mon May 31 00:09:34 2010
Thread 1 advanced to log sequence 8857 (LGWR switch)
Current log# 1 seq# 8857 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 00:10:33 2010
Thread 1 advanced to log sequence 8858 (LGWR switch)
Current log# 2 seq# 8858 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Mon May 31 00:11:38 2010
Thread 1 advanced to log sequence 8859 (LGWR switch)
Current log# 3 seq# 8859 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Mon May 31 00:16:13 2010
Thread 1 advanced to log sequence 8860 (LGWR switch)
Current log# 1 seq# 8860 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 00:20:09 2010
Thread 1 advanced to log sequence 8861 (LGWR switch)
Current log# 2 seq# 8861 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Mon May 31 00:21:28 2010
Thread 1 advanced to log sequence 8862 (LGWR switch)
Current log# 3 seq# 8862 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Mon May 31 00:22:37 2010
Thread 1 advanced to log sequence 8863 (LGWR switch)
Current log# 1 seq# 8863 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 00:25:42 2010
Thread 1 advanced to log sequence 8864 (LGWR switch)
Current log# 2 seq# 8864 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Mon May 31 00:26:47 2010
Thread 1 advanced to log sequence 8865 (LGWR switch)
Current log# 3 seq# 8865 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Mon May 31 00:29:52 2010
Thread 1 advanced to log sequence 8866 (LGWR switch)
Current log# 1 seq# 8866 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 10:43:39 2010
Thread 1 advanced to log sequence 8867 (LGWR switch)
Current log# 2 seq# 8867 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Mon May 31 11:30:27 2010
Thread 1 advanced to log sequence 8868 (LGWR switch)
Current log# 3 seq# 8868 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Mon May 31 12:57:56 2010
Thread 1 advanced to log sequence 8869 (LGWR switch)
Current log# 1 seq# 8869 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 15:19:50 2010
Thread 1 advanced to log sequence 8870 (LGWR switch)
Current log# 2 seq# 8870 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Mon May 31 22:00:52 2010
Thread 1 advanced to log sequence 8871 (LGWR switch)
Current log# 3 seq# 8871 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Mon May 31 22:01:02 2010
Thread 1 advanced to log sequence 8872 (LGWR switch)
Current log# 1 seq# 8872 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 22:01:27 2010
Thread 1 advanced to log sequence 8873 (LGWR switch)
Current log# 2 seq# 8873 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Mon May 31 22:01:47 2010
Thread 1 advanced to log sequence 8874 (LGWR switch)
Current log# 3 seq# 8874 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Mon May 31 22:02:09 2010
Thread 1 advanced to log sequence 8875 (LGWR switch)
Current log# 1 seq# 8875 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 22:02:24 2010
Thread 1 advanced to log sequence 8876 (LGWR switch)
Current log# 2 seq# 8876 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Mon May 31 22:02:30 2010
Thread 1 advanced to log sequence 8877 (LGWR switch)
Current log# 3 seq# 8877 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Mon May 31 22:02:37 2010
Thread 1 advanced to log sequence 8878 (LGWR switch)
Current log# 1 seq# 8878 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 22:02:45 2010
Thread 1 advanced to log sequence 8879 (LGWR switch)
Current log# 2 seq# 8879 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Mon May 31 22:02:50 2010
Thread 1 advanced to log sequence 8880 (LGWR switch)
Current log# 3 seq# 8880 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Mon May 31 22:02:54 2010
Thread 1 advanced to log sequence 8881 (LGWR switch)
Current log# 1 seq# 8881 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Mon May 31 22:02:58 2010
Thread 1 advanced to log sequence 8882 (LGWR switch)
Current log# 2 seq# 8882 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Mon May 31 22:03:15 2010
Thread 1 advanced to log sequence 8883 (LGWR switch)
Current log# 3 seq# 8883 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Dump file h:\admin\MYDB\bdump\alert_MYDB.log
Tue Jun 01 00:01:05 2010
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows NT Version V6.0 Service Pack 2
CPU                 : 8 - type 8664, 8 Physical Cores
Process Affinity    : 0x0000000000000000
Memory (Avail/Total): Ph:18247M/20477M, Ph+PgF:36004M/37825M
Tue Jun 01 00:01:05 2010
Starting ORACLE instance (restrict)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters with non-default values:
processes                = 150
__shared_pool_size       = 1526726656
__large_pool_size        = 0
__java_pool_size         = 16777216
__streams_pool_size      = 0
nls_language             = AMERICAN
nls_territory            = AMERICA
sga_target               = 10737418240
control_files            = E:\ORADATA\MYDB\CONTROL01.CTL, F:\ORADATA\MYDB\CONTROL02.CTL, H:\ORADATA\MYDB\CONTROL03.CTL
db_block_size            = 8192
__db_cache_size          = 9177137152
compatible               = 10.2.0.3.0
log_archive_dest_1       = LOCATION=g:\archives\MYDB
log_archive_format       = ARC%S_%R.%T
db_file_multiblock_read_count= 16
undo_management          = AUTO
undo_tablespace          = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain                =
dispatchers              = (PROTOCOL=TCP) (SERVICE=MYDBXDB)
local_listener           = (ADDRESS=(PROTOCOL=TCP)(HOST=192.2.6.154)(PORT=1521))
remote_dependencies_mode = SIGNATURE
job_queue_processes      = 10
audit_file_dest          = H:\ADMIN\MYDB\ADUMP
background_dump_dest     = H:\ADMIN\MYDB\BDUMP
user_dump_dest           = H:\ADMIN\MYDB\UDUMP
core_dump_dest           = H:\ADMIN\MYDB\CDUMP
db_name                  = MYDB
open_cursors             = 300
pga_aggregate_target     = 1073741824
PMON started with pid=2, OS id=2724
PSP0 started with pid=3, OS id=5088
MMAN started with pid=4, OS id=4436
DBW0 started with pid=5, OS id=4400
LGWR started with pid=6, OS id=792
CKPT started with pid=7, OS id=4036
SMON started with pid=8, OS id=4220
RECO started with pid=9, OS id=1856
CJQ0 started with pid=10, OS id=332
MMON started with pid=11, OS id=4224
Tue Jun 01 00:01:05 2010
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=4784
Tue Jun 01 00:01:05 2010
starting up 1 shared server(s) ...
Oracle Data Guard is not available in this edition of Oracle.
Tue Jun 01 00:01:05 2010
alter database "MYDB" mount exclusive
Tue Jun 01 00:01:10 2010
Setting recovery target incarnation to 2
Tue Jun 01 00:01:10 2010
Successful mount of redo thread 1, with mount id 4241292930
Tue Jun 01 00:01:10 2010
Database mounted in Exclusive Mode
Completed: alter database "MYDB" mount exclusive
Tue Jun 01 00:01:10 2010
alter database open
Tue Jun 01 00:01:10 2010
Beginning crash recovery of 1 threads
Tue Jun 01 00:01:10 2010
Started redo scan
Tue Jun 01 00:01:11 2010
Completed redo scan
893 redo blocks read, 96 data blocks need recovery
Tue Jun 01 00:01:11 2010
Started redo application at
Thread 1: logseq 8883, block 18558
Tue Jun 01 00:01:11 2010
Recovery of Online Redo Log: Thread 1 Group 3 Seq 8883 Reading mem 0
Mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Tue Jun 01 00:01:11 2010
Completed redo application
Tue Jun 01 00:01:11 2010
Completed crash recovery at
Thread 1: logseq 8883, block 19451, scn 283448451
96 data blocks read, 96 data blocks written, 893 redo blocks read
Tue Jun 01 00:01:11 2010
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=16, OS id=1804
Tue Jun 01 00:01:11 2010
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started with pid=17, OS id=4988
Tue Jun 01 00:01:11 2010
Thread 1 advanced to log sequence 8884 (thread open)
Thread 1 opened at log sequence 8884
Current log# 1 seq# 8884 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Successful open of redo thread 1
Tue Jun 01 00:01:11 2010
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
Tue Jun 01 00:01:11 2010
ARC0: Becoming the heartbeat ARCH
Tue Jun 01 00:01:11 2010
SMON: enabling cache recovery
Tue Jun 01 00:01:11 2010
Successfully onlined Undo Tablespace 1.
Tue Jun 01 00:01:11 2010
SMON: enabling tx recovery
Tue Jun 01 00:01:11 2010
Database Characterset is WE8ISO8859P1
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=18, OS id=244
Tue Jun 01 00:01:13 2010
Completed: alter database open
Tue Jun 01 00:01:13 2010
ALTER SYSTEM disable restricted session;
Tue Jun 01 00:07:16 2010
Thread 1 advanced to log sequence 8885 (LGWR switch)
Current log# 2 seq# 8885 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Tue Jun 01 00:10:00 2010
Thread 1 advanced to log sequence 8886 (LGWR switch)
Current log# 3 seq# 8886 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Tue Jun 01 00:10:58 2010
Thread 1 advanced to log sequence 8887 (LGWR switch)
Current log# 1 seq# 8887 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Tue Jun 01 00:12:03 2010
Thread 1 advanced to log sequence 8888 (LGWR switch)
Current log# 2 seq# 8888 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Tue Jun 01 00:16:44 2010
Thread 1 advanced to log sequence 8889 (LGWR switch)
Current log# 3 seq# 8889 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Tue Jun 01 00:20:52 2010
Thread 1 advanced to log sequence 8890 (LGWR switch)
Current log# 1 seq# 8890 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Tue Jun 01 00:22:10 2010
Thread 1 advanced to log sequence 8891 (LGWR switch)
Current log# 2 seq# 8891 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Tue Jun 01 00:23:28 2010
Thread 1 advanced to log sequence 8892 (LGWR switch)
Current log# 3 seq# 8892 mem# 0: H:\ORADATA\MYDB\REDO03.LOG
Tue Jun 01 00:27:03 2010
Thread 1 advanced to log sequence 8893 (LGWR switch)
Current log# 1 seq# 8893 mem# 0: H:\ORADATA\MYDB\REDO01.LOG
Tue Jun 01 00:28:23 2010
Thread 1 advanced to log sequence 8894 (LGWR switch)
Current log# 2 seq# 8894 mem# 0: H:\ORADATA\MYDB\REDO02.LOG
Tue Jun 01 00:32:03 2010
Thread 1 advanced to log sequence 8895 (LGWR switch)
Current log# 3 seq# 8895 mem# 0: H:\ORADATA\MYDB\REDO03.LOG

Crash recovery for zones

hi,
What's the best way for crash recovery for zones?
Thanks,
Rosario

there are some recipes using the snapshot feature of ZFS systems. I tried a solution for non ZFS filesystems:
to backup:
df -F nfs | sed "s/ .*//" > /tmp/excludes # this excludes NFS mounted filesystems
find /$zonepath/$zonename -fstype lofs -prune 2> /dev/null | sed "s/^\/$zonepath\///">> /tmp/excludes # this exclude LOFS mounted filesystems
echo "$zonename/root/proc" >> /tmp/excludes
echo "$zonename/root/var/run" >> /tmp/excludes
echo "$zonename/root/system/contract/all" >> /tmp/excludes
echo "$zonename/root/system/contract/process" >> /tmp/excludes
echo "$zonename/root/etc/mnttab" >> /tmp/excludes
echo "$zonename/root/etc/svc/volatile" >> /tmp/excludes
echo "$zonename/root/system/object" >> /tmp/excludes
echo "$zonename/root/tmp" >> /tmp/excludes
echo "$zonename/root/var/svc/log" >> /tmp/excludes
echo "$zonename/root/var/log/syslog*" >> /tmp/excludes
echo "$zonename/root/var/saf/zsmon/log" >> /tmp/excludes
echo "$zonename/root/var/adm/messages*" >> /tmp/excludes
echo "$zonename/root/var/adm/wtmpx" >> /tmp/excludes
echo "$zonename/root/etc/svc/volatile/repository_door" >> /tmp/excludes
echo "$zonename/root/tmp/.X11-unix/X0" >> /tmp/excludes
echo "$zonename/dev/.devfsadm_synch_door" >> /tmp/excludes
cd /$zonepath
tar -EcfX /$somepath/$zonename.tar /tmp/excludes $zonename 2> /tmp/$zonename.err
to restore:
extract tar
mkdir of all mount points
mkdir for all dynamic data (i.e. $zonename/root/proc), assigning correct permissions&ownership
create files for all dynamic data (i.e. $zonename/root/etc/mnttab), assigning correct permissions&ownership
this solution requires that the backed up machine, and the restored one, to have the same OS level and patches

After crash, recovery, new drive install: "locked disk/write permissions"?

After this trauma, I've already had the installing tech redo the generic Home setup they did (originals were lost) as there were tangled permissions, users, etc.. They did add the iLife 06 suite to the reinstall, and then I upgraded back it '08.
Now, iTunes and iPhoto give the message: "The folder (X) is on a locked disk or you do not have write permissions for this folder." What? Why? And why just these two?

Hi Larry,
Could be many things, we should start with this...
"Try Disk Utility
1. Insert the Mac OS X Install disc that came with your computer, then restart the computer while holding the C key.
2. When your computer finishes starting up from the disc, choose Disk Utility from the Installer menu. (In Mac OS X 10.4 or later, you must select your language first.)
Important: Do not click Continue in the first screen of the Installer. If you do, you must restart from the disc again to access Disk Utility.
3. Click the First Aid tab.
4. Click the disclosure triangle to the left of the hard drive icon to display the names of your hard disk volumes and partitions.
5. Select your Mac OS X volume.
6. Click Repair. Disk Utility checks and repairs the disk."
http://docs.info.apple.com/article.html?artnum=106214
Then Safe Boot from the HD, (holding Shift key down at bootup), run Disk Utility in Applications>Utilities, then highlight your drive, click on Repair Permissions, reboot when it finishes.
The usual reason why updates fail or mess things up, or things don't load/run, is if Permissions are not fixed before & after every update, with a reboot... you may get a partial update when the installer finds it doesn't have Permissions to change one obscure little part of the OS, leaving you with a mix of OS versions.
Some people get away without Repairing Permissions for years, some for only days.
If Permissions are wrong before applying an update, you could get mixed OS versions, if Directory is the slightest messed up, who knows!
If many Permission are repaired, or any Directory errors are found, you may need to re-apply some the latest/biggest updates again, or even do an A&I if you have enough free disk space.
The combo update for PowerPC-based Macs...
http://www.apple.com/support/downloads/macosx10411comboupdateppc.html
The combo update for Intel-based Macs...
http://www.apple.com/support/downloads/macosx10411comboupdateintel.html
Repair Permissions after re-install, then reboot again.
If all the above do not resolve the problem, then it's time for an Archive & Install, which gives you a new OS, but can preserve all your files, pics, music, settings, etc., as long as you have plenty of free disk space...
http://docs.info.apple.com/article.html?artnum=107120

Mac crash; recovery will not start

Yesterday my Mac suddenly crashed into a screen with blue (and white) lines. It wouldn't respond to anything, so I powered it down and tried to boot again. However, it will not boot. It will show the Apple logo, request my password and after a while (with the Apple logo and the spinning wheel) it just shows a blank screen (grey), while the CPU fans are spinning like crazy.Sometimes will it not even get this far and stop doing anything before requesting the password. The guest mode has the same problem.
I basically tried everything to fix it; the recovery option will also show the blank grey screen but nothing else (even after 30 minutes); the internet recovery downloads fine and then pulls the same stunt, so even the recovery will not work. I've tried save mode, which cannot start up (Filevault is activated) and seems to end mid-way through. Sometimes the safe mode crashes immediately after the boot starts with a kernel panic (/sbin/launchd failed, errno 2); after resetting the NVRAM it won't panic.
I've checked the hardware (T startup option, full check), which al seems to be OK. SMART status from the harddrive looks OK (checked with DiskWarrior). Starting in single user mode sometimes gets me through the password request screen and allows me to check the hard drive (fsck -fy). This seems to change permissions, however, after a reboot or exit command, the problem persists and starting up in single user mode and performing the fsck -fy command again seems to fix some issues. When I enter the exit command in safe mode, it'll start up fine, but when the graphic user interface starts, it'll give me the grey screen again (so a blank screen, while the CPU fans are at full power).
Does anyone have any idea what I can do to fix this? Since even the recovery will not start (and neither will the internet recovery), I've got no clue what to do to fix this issue...

Your comment about the "blue and white lines" has me wondering. You say you have a fairly recent MacBook Pro, correct? If that is the case, you probably have a model which has both discrete and integrated GPUs. It is possible that your discrete GPU has failed, and whenever the OS is trying to switch to it is when your system just "hangs" (because the GPU has failed). It all works properly as long as it is on the integrated GPU, but when something causes it to switch it hits the bad GPU and locks.
I would suggest that you make an appointment at your nearest Apple Store to have the specialists at the Genius Bar take a look at it for you. If you are still under the 1 year warranty (or extended Apple Care if you purchased it) then any needed hardware repairs would be free, unless it is due to accidental damage such as a spill in the keyboard, etc.
If you don't have access to an Authorized Apple Service Center, and you do have access to another Mac, you could try making an external boot drive on the other Mac, then install the app "gfxCardStatus" on that MacOS instance (when booted from the external drive). While still booted from the external drive, use the gfxCardStatus app to force the Mac to only use the integrated GPU then shutdown and boot your "dead" Mac from that drive. If it boots and runs, now, try to change the external drive to force to use only the discrete GPU then see how your system boots. If your system, will fully boot using one or the other, then it seems that your problem is probably related to one of your GPUs. It could be a hardware failure, or it could be a corrupted driver. If your system won't boot from either GPU, then my guess about it being a GPU issue is probably wrong.

IPhone lock-up, crash & rebooting issues?

Hi, All – I have the original iPhone with 2.0 software. Since the initial install and even after doing a restore on it, the phone has been crashing and rebooting intermittently. I am using AT&T service, and I have never attempted to unlock the phone or run arbitrary code on it, so these issues are baffling to me. Below is a brief list of what I’ve encountered. Again, the iPhone is crashing and rebooting, not the apps:
Press the “Home” button = intermittent crash, then reboot (might happen back to back, or as infrequently as 6 hours – no rhyme or reason)
Press the “Power” button = (same result as above)
Phone locked up when receiving a call, lit up & identified the caller, no ring or vibration then it rebooted. This has happened twice.
Phone locked up when receiving a text message. Noticed it as I heard an odd tone from my phone for a split second, then it crashed and rebooted and showed a text message on the home screen when it finished rebooting.
Also, I have had other problems where the phone didn’t crash or reboot – it just didn’t perform properly:
When receiving a call – display does not light; phone does not ring or buzz. Voicemail received from caller though call not noted in received calls list. Also, I have had a greater number of “Call Failed” problems, even with full cell signal in Denver, CO. This may be AT&T’s fault, but it seems fine after I shut down and restart the phone.
In general, my iPhone with 2.0 software seems a bit more laggy. Screen rotation from portrait to landscape isn’t as smooth and opening the SMS app seems to have a consistent 2-second delay regardless of if I have cleared out my text message logs or not.
Also, when I reboot the phone, more often than not it starts off at the “slide to unlock” screen instead of the home screen.
Regarding location services – My gripe is that it can’t be told to either:
Stay on all the time
Shut off all the time
Activate when needed, then shut off – just like in 1.1.4.
Now when I use an application that I allow to use location services, I have to manually go and shut location services off again or my battery life will suffer.
I have now removed all of the new applications from the phone, and am still experiencing crash/reboot problems. My guess is my phone is damaged somehow or the software I downloaded was somehow flawed during downloading or installation.
Does anyone have any ideas? I really like this phone, but I can't bring myself to buy the new 3G if I can't be certain I wouldn't have the same problems
Thank you,
Lynn

I have experienced this problem as well and it is intermittent to say the least. I have two other friends that have an i-phone as well, and when the phone crashed it stored a picture of the screen in the photo library of the phone. I thought that was a little odd as well. I have another friend that has not updated to 2.0 yet and does not seem to be having any problems at all. I would venture to guess that there is a problem with the update and that an update will be out sometime to correct the problem. If anyone knows of a way to correct the problem please post a fix for us.

Gv$global_transaction locked in crash(?) recovery

Similar Messages

Maybe you are looking for