D:\APP\ADMINISTRATOR\ORADATA\UIDB\CONTROL01.CTL快速恢复区满了，或 D 盘满了，手动清理一下。
D盘空间还有40多G，应该不是磁盘空间满的问题！几天早上又发生了，这次能从本地登录服务器，但是其上所有应用都结束了，数据库也是连接不上，重启后恢复！ Fri Jul 04 03:15:48 2014 ***********************************************************************Fatal NI connect error 12638, connecting to: (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) VERSION INFORMATION: TNS for 64-bit Windows: Version 11.2.0.1.0 - Production Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production Time: 04-7月 -2014 03:15:48 Tracing not turned on. Tns error struct: ns main err code: 12638
TNS-12638: 身份证明检索失败 ns secondary err code: 0 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 Fri Jul 04 03:18:51 2014 Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 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 =27 LICENSE_MAX_USERS = 0 SYS auditing is disabled这个是昨天重启后清除alert日志后产生的新日志，大神们帮看看，数据库为啥又要歇菜！
接楼上日志 Starting up: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options. Using parameter settings in server-side spfile D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\SPFILEUIDB.ORA System parameters with non-default values: processes = 150 memory_target = 1G memory_max_target = 2G control_files = "D:\APP\ADMINISTRATOR\ORADATA\UIDB\CONTROL01.CTL" control_files = "D:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\UIDB\CONTROL02.CTL" db_block_size = 8192 compatible = "11.2.0.0.0" db_recovery_file_dest = "D:\app\Administrator\flash_recovery_area" db_recovery_file_dest_size= 3912M undo_tablespace = "UNDOTBS1" remote_login_passwordfile= "EXCLUSIVE" db_domain = "" dispatchers = "(PROTOCOL=TCP) (SERVICE=uidbXDB)" audit_file_dest = "D:\APP\ADMINISTRATOR\ADMIN\UIDB\ADUMP" audit_trail = "DB" db_name = "uidb" open_cursors = 4000 diagnostic_dest = "D:\APP\ADMINISTRATOR" Fri Jul 04 03:19:02 2014 PMON started with pid=2, OS id=2412 Fri Jul 04 03:19:02 2014 VKTM started with pid=3, OS id=2416 at elevated priority VKTM running at (10)millisec precision with DBRM quantum (100)ms Fri Jul 04 03:19:02 2014 GEN0 started with pid=4, OS id=2420 Fri Jul 04 03:19:02 2014 DIAG started with pid=5, OS id=2424 Fri Jul 04 03:19:02 2014 DBRM started with pid=6, OS id=2428 Fri Jul 04 03:19:02 2014 PSP0 started with pid=7, OS id=2432 Fri Jul 04 03:19:02 2014 DIA0 started with pid=8, OS id=2436 Fri Jul 04 03:19:02 2014 MMAN started with pid=9, OS id=2440 Fri Jul 04 03:19:02 2014 DBW0 started with pid=10, OS id=2444 Fri Jul 04 03:19:02 2014 LGWR started with pid=11, OS id=2448 Fri Jul 04 03:19:02 2014 CKPT started with pid=12, OS id=2452 Fri Jul 04 03:19:02 2014 SMON started with pid=13, OS id=2456 Fri Jul 04 03:19:02 2014 RECO started with pid=14, OS id=2460 Fri Jul 04 03:19:02 2014 MMON started with pid=15, OS id=2464 Fri Jul 04 03:19:02 2014 starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'... Fri Jul 04 03:19:02 2014 MMNL started with pid=16, OS id=2468 starting up 1 shared server(s) ... ORACLE_BASE from environment = D:\app\Administrator Fri Jul 04 03:19:05 2014 alter database mount exclusive Successful mount of redo thread 1, with mount id 686344361 Database mounted in Exclusive Mode Lost write protection disabled Completed: alter database mount exclusive alter database open Fri Jul 04 03:19:18 2014 Beginning crash recovery of 1 threads parallel recovery started with 7 processes Started redo scan Completed redo scan read 583 KB redo, 90 data blocks need recovery Started redo application at Thread 1: logseq 2893, block 37660 Recovery of Online Redo Log: Thread 1 Group 1 Seq 2893 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\UIDB\REDO01.LOG Completed redo application of 0.30MB Completed crash recovery at Thread 1: logseq 2893, block 38826, scn 159716486 90 data blocks read, 90 data blocks written, 583 redo k-bytes read Fri Jul 04 03:19:20 2014 Thread 1 advanced to log sequence 2894 (thread open) Thread 1 opened at log sequence 2894 Current log# 2 seq# 2894 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\UIDB\REDO02.LOG Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Fri Jul 04 03:19:20 2014 SMON: enabling cache recovery Successfully onlined Undo Tablespace 2. Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed SMON: enabling tx recovery Database Characterset is AL32UTF8 No Resource Manager plan active Fri Jul 04 03:19:28 2014 replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC Fri Jul 04 03:19:34 2014 QMNC started with pid=27, OS id=2960 Fri Jul 04 03:19:39 2014 Completed: alter database open Fri Jul 04 03:19:43 2014 Starting background process CJQ0 Fri Jul 04 03:19:43 2014 CJQ0 started with pid=34, OS id=3312 Fri Jul 04 03:19:43 2014 db_recovery_file_dest_size of 3912 MB is 0.00% 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. Fri Jul 04 03:26:05 2014 Starting background process SMCO Fri Jul 04 03:26:05 2014 SMCO started with pid=22, OS id=5908
Fri Jul 04 03:15:48 2014
***********************************************************************Fatal NI connect error 12638, connecting to:
(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) VERSION INFORMATION:
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Time: 04-7月 -2014 03:15:48
Tracing not turned on.
Tns error struct:
ns main err code: 12638
TNS-12638: 身份证明检索失败
ns secondary err code: 0
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
Fri Jul 04 03:18:51 2014
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 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 =27
LICENSE_MAX_USERS = 0
SYS auditing is disabled这个是昨天重启后清除alert日志后产生的新日志，大神们帮看看，数据库为啥又要歇菜！
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\SPFILEUIDB.ORA
System parameters with non-default values:
processes = 150
memory_target = 1G
memory_max_target = 2G
control_files = "D:\APP\ADMINISTRATOR\ORADATA\UIDB\CONTROL01.CTL"
control_files = "D:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\UIDB\CONTROL02.CTL"
db_block_size = 8192
compatible = "11.2.0.0.0"
db_recovery_file_dest = "D:\app\Administrator\flash_recovery_area"
db_recovery_file_dest_size= 3912M
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=uidbXDB)"
audit_file_dest = "D:\APP\ADMINISTRATOR\ADMIN\UIDB\ADUMP"
audit_trail = "DB"
db_name = "uidb"
open_cursors = 4000
diagnostic_dest = "D:\APP\ADMINISTRATOR"
Fri Jul 04 03:19:02 2014
PMON started with pid=2, OS id=2412
Fri Jul 04 03:19:02 2014
VKTM started with pid=3, OS id=2416 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Fri Jul 04 03:19:02 2014
GEN0 started with pid=4, OS id=2420
Fri Jul 04 03:19:02 2014
DIAG started with pid=5, OS id=2424
Fri Jul 04 03:19:02 2014
DBRM started with pid=6, OS id=2428
Fri Jul 04 03:19:02 2014
PSP0 started with pid=7, OS id=2432
Fri Jul 04 03:19:02 2014
DIA0 started with pid=8, OS id=2436
Fri Jul 04 03:19:02 2014
MMAN started with pid=9, OS id=2440
Fri Jul 04 03:19:02 2014
DBW0 started with pid=10, OS id=2444
Fri Jul 04 03:19:02 2014
LGWR started with pid=11, OS id=2448
Fri Jul 04 03:19:02 2014
CKPT started with pid=12, OS id=2452
Fri Jul 04 03:19:02 2014
SMON started with pid=13, OS id=2456
Fri Jul 04 03:19:02 2014
RECO started with pid=14, OS id=2460
Fri Jul 04 03:19:02 2014
MMON started with pid=15, OS id=2464
Fri Jul 04 03:19:02 2014
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Fri Jul 04 03:19:02 2014
MMNL started with pid=16, OS id=2468
starting up 1 shared server(s) ...
ORACLE_BASE from environment = D:\app\Administrator
Fri Jul 04 03:19:05 2014
alter database mount exclusive
Successful mount of redo thread 1, with mount id 686344361
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount exclusive
alter database open
Fri Jul 04 03:19:18 2014
Beginning crash recovery of 1 threads
parallel recovery started with 7 processes
Started redo scan
Completed redo scan
read 583 KB redo, 90 data blocks need recovery
Started redo application at
Thread 1: logseq 2893, block 37660
Recovery of Online Redo Log: Thread 1 Group 1 Seq 2893 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\UIDB\REDO01.LOG
Completed redo application of 0.30MB
Completed crash recovery at
Thread 1: logseq 2893, block 38826, scn 159716486
90 data blocks read, 90 data blocks written, 583 redo k-bytes read
Fri Jul 04 03:19:20 2014
Thread 1 advanced to log sequence 2894 (thread open)
Thread 1 opened at log sequence 2894
Current log# 2 seq# 2894 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\UIDB\REDO02.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Jul 04 03:19:20 2014
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
Fri Jul 04 03:19:28 2014
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Fri Jul 04 03:19:34 2014
QMNC started with pid=27, OS id=2960
Fri Jul 04 03:19:39 2014
Completed: alter database open
Fri Jul 04 03:19:43 2014
Starting background process CJQ0
Fri Jul 04 03:19:43 2014
CJQ0 started with pid=34, OS id=3312
Fri Jul 04 03:19:43 2014
db_recovery_file_dest_size of 3912 MB is 0.00% 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.
Fri Jul 04 03:26:05 2014
Starting background process SMCO
Fri Jul 04 03:26:05 2014
SMCO started with pid=22, OS id=5908
另外， 你的oracle的 参数中 sga，pga是多少？
还有是，如果再出现这个问题，你先通过任务管理器看看 ，内存，或者cpu上会不会有异常的地方