最新文章專題視頻專題問答1問答10問答100問答1000問答2000關(guān)鍵字專題1關(guān)鍵字專題50關(guān)鍵字專題500關(guān)鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關(guān)鍵字專題關(guān)鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
當(dāng)前位置: 首頁 - 科技 - 知識百科 - 正文

一次vm虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle數(shù)據(jù)庫啟動故障

來源:懂視網(wǎng) 責(zé)編:小采 時(shí)間:2020-11-09 14:54:54
文檔

一次vm虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle數(shù)據(jù)庫啟動故障

一次vm虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle數(shù)據(jù)庫啟動故障:一次vm 虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle 數(shù)據(jù)庫啟動故障 本文是原創(chuàng)文章,若轉(zhuǎn)載請注明出處: http://blog.csdn.net/msdnchina/article/details/38782163 直接上數(shù)據(jù)庫的alert日志: Fri Apr 25 22:00:54 2014 -----注意該時(shí)間
推薦度:
導(dǎo)讀一次vm虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle數(shù)據(jù)庫啟動故障:一次vm 虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle 數(shù)據(jù)庫啟動故障 本文是原創(chuàng)文章,若轉(zhuǎn)載請注明出處: http://blog.csdn.net/msdnchina/article/details/38782163 直接上數(shù)據(jù)庫的alert日志: Fri Apr 25 22:00:54 2014 -----注意該時(shí)間

一次vm 虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle 數(shù)據(jù)庫啟動故障 本文是原創(chuàng)文章,若轉(zhuǎn)載請注明出處: http://blog.csdn.net/msdnchina/article/details/38782163 直接上數(shù)據(jù)庫的alert日志: Fri Apr 25 22:00:54 2014 -----注意該時(shí)間Archived Log entry 1766 added f

一次vm 虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle 數(shù)據(jù)庫啟動故障

本文是原創(chuàng)文章,若轉(zhuǎn)載請注明出處:

http://blog.csdn.net/msdnchina/article/details/38782163

直接上數(shù)據(jù)庫的alert日志:

Fri Apr 25 22:00:54 2014 <-----注意該時(shí)間
Archived Log entry 1766 added for thread 1 sequence 1770 ID 0x4e0785c3 dest 1:
Sun Sep 02 23:04:52 2012 <-----注意該時(shí)間
Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 32 KB
 
Total Shared Global Region in Large Pages = 0 KB (0%)
 
Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 0 (0 KB)
Large Page size = 2048 KB
 
RECOMMENDATION:
 Total System Global Area size is 4226 MB. For optimal performance,
 prior to the next instance restart:
 1. Increase the number of unused large pages by 
 at least 2113 (page size 2048 KB, total size 4226 MB) system wide to
 get 100% of the System Global Area allocated with large pages
 2. Large pages are automatically locked into physical memory.
 Increase the per process memlock (soft) limit to at least 4234 MB to lock
 100% System Global Area's large pages into physical memory
********************************************************************
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 4
CELL communication is configured to use 0 interface(s):
CELL IP affinity details:
 NUMA status: non-NUMA system
 cellaffinity.ora status: N/A
CELL communication will use 1 IP group(s):
 Grp 0: 
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =51
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
ORACLE_HOME = /opt/oracle/product/11g/dbname_1
System name: Linux
Node name: oracle
Release: 2.6.18-371.el5
Version: #1 SMP Thu Sep 5 21:21:44 EDT 2013
Machine: x86_64
VM name: VMWare Version: 6
Using parameter settings in server-side spfile /opt/oracle/product/11g/dbname_1/dbs/spfileorcl.ora
System parameters with non-default values:
 processes = 300
 sessions = 472
 nls_language = "SIMPLIFIED CHINESE"
 nls_territory = "CHINA"
 sga_target = 4224M
 control_files = "/oracledata/orcl/control01.ctl"
 control_files = "/opt/oracle/fast_recovery_area/orcl/control02.ctl"
 control_files = "/oracledata/orcl/control03.ctl"
 control_files = "/oracledata/orcl/control04.ctl"
 control_files = "/oracledata/orcl/control05.ctl"
 db_block_size = 8192
 compatible = "11.2.0.4.0"
 log_archive_format = "%t_%s_%r.dbf"
 db_files = 2000
 db_recovery_file_dest = "/opt/oracle/fast_recovery_area"
 db_recovery_file_dest_size= 40G
 undo_tablespace = "UNDOTBS1"
 remote_login_passwordfile= "EXCLUSIVE"
 db_domain = ""
 dispatchers = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
 audit_file_dest = "/opt/oracle/admin/orcl/adump"
 audit_trail = "DB"
 db_name = "orcl"
 open_cursors = 300
 pga_aggregate_target = 1403M
 deferred_segment_creation= FALSE
 diagnostic_dest = "/opt/oracle"
Sun Sep 02 23:04:53 2012
PMON started with pid=2, OS id=4452 
Sun Sep 02 23:04:53 2012
PSP0 started with pid=3, OS id=4454 
Sun Sep 02 23:04:54 2012
VKTM started with pid=4, OS id=4456 at elevated priority
Sun Sep 02 23:04:54 2012
GEN0 started with pid=5, OS id=4460 
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Sun Sep 02 23:04:54 2012
DIAG started with pid=6, OS id=4462 
Sun Sep 02 23:04:54 2012
DBRM started with pid=7, OS id=4464 
Sun Sep 02 23:04:54 2012
DIA0 started with pid=8, OS id=4466 
Sun Sep 02 23:04:54 2012
MMAN started with pid=9, OS id=4468 
Sun Sep 02 23:04:54 2012
DBW0 started with pid=10, OS id=4470 
Sun Sep 02 23:04:54 2012
LGWR started with pid=11, OS id=4472 
Sun Sep 02 23:04:54 2012
CKPT started with pid=12, OS id=4474 
Sun Sep 02 23:04:54 2012
SMON started with pid=13, OS id=4476 
Sun Sep 02 23:04:54 2012
RECO started with pid=14, OS id=4478 
Sun Sep 02 23:04:55 2012
MMON started with pid=15, OS id=4480 
Sun Sep 02 23:04:55 2012
MMNL started with pid=16, OS id=4482 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /opt/oracle
Sun Sep 02 23:04:55 2012
ALTER DATABASE MOUNT
Successful mount of redo thread 1, with mount id 1320728727
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE MOUNT
Sun Sep 02 23:04:59 2012
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 3 processes
Started redo scan
Completed redo scan
 read 69 KB redo, 66 data blocks need recovery
Started redo application at
 Thread 1: logseq 1771, block 16853
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1771 Reading mem 0
 Mem# 0: /oracledata/orcl/redo01.log
Completed redo application of 0.04MB
Completed crash recovery at
 Thread 1: logseq 1771, block 16992, scn 13030631482598
 66 data blocks read, 66 data blocks written, 69 redo k-bytes read
************************************************************
Warning: The SCN headroom for this database is only -652 hours!
************************************************************
Errors in file /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4492.trc (incident=43353):
ORA-00600: internal error code, arguments: [kcm_headroom_warn_1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /opt/oracle/diag/rdbms/orcl/orcl/incident/incdir_43353/orcl_ora_4492_i43353.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4492.trc:
ORA-00600: internal error code, arguments: [kcm_headroom_warn_1], [], [], [], [], [], [], [], [], [], [], []
ORA-600 signalled during: ALTER DATABASE OPEN...
Dumping diagnostic data in directory=[cdmp_20120902230501], requested by (instance=1, osid=4492), summary=[incident=43353].
Sun Sep 02 23:05:58 2012
Sweep [inc][43353]: completed
Sweep [inc2][43353]: completed
Sun Sep 02 23:19:58 2012
db_recovery_file_dest_size of 40960 MB is 29.05% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Sun Sep 02 23:38:25 2012

聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

文檔

一次vm虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle數(shù)據(jù)庫啟動故障

一次vm虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle數(shù)據(jù)庫啟動故障:一次vm 虛擬機(jī)時(shí)間倒流而導(dǎo)致的oracle 數(shù)據(jù)庫啟動故障 本文是原創(chuàng)文章,若轉(zhuǎn)載請注明出處: http://blog.csdn.net/msdnchina/article/details/38782163 直接上數(shù)據(jù)庫的alert日志: Fri Apr 25 22:00:54 2014 -----注意該時(shí)間
推薦度:
  • 熱門焦點(diǎn)

最新推薦

猜你喜歡

熱門推薦

專題
Top