寫了好多，但看不出什么端倪來，以下是斷前的最后記錄：

Tue Apr 03 16:18:21 2007

ORACLE V9.2.0.1.0 - Production vsnsta=0

vsnsql=12 vsnxtr=3

Windows 2000 Version 5.2 , CPU type 586

Tue Apr 03 16:18:21 2007

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

SCN scheme 2

Using log_archive_dest parameter default value

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up ORACLE RDBMS Version: 9.2.0.1.0.

System parameters with non-default values:

processes? ?? ?? ?? ?? ? = 150

timed_statistics? ?? ?? ?= TRUE

shared_pool_size? ?? ?? ?= 209715200

sga_max_size? ?? ?? ?? ? = 1578182572

large_pool_size? ?? ?? ? = 25165824

java_pool_size? ?? ?? ???= 33554432

control_files? ?? ?? ?? ?= e:\ora92\oradata\ynsjzzf\CONTROL01.CTL, e:\ora92\oradata\ynsjzzf\CONTROL02.CTL, e:\ora92\oradata\ynsjzzf\CONTROL03.CTL

db_block_size? ?? ?? ?? ?= 8192

db_cache_size? ?? ?? ?? ?= 1258291200

compatible? ?? ?? ?? ?? ?= 9.2.0.0.0

db_file_multiblock_read_count= 16

fast_start_mttr_target? ?= 300

dml_locks? ?? ?? ?? ?? ? = 1200

undo_management? ?? ?? ? = AUTO

undo_tablespace? ?? ?? ? = UNDOTBS1

undo_retention? ?? ?? ???= 10800

remote_login_passwordfile= EXCLUSIVE

db_domain? ?? ?? ?? ?? ? =

instance_name? ?? ?? ?? ?= ynsjzzf

dispatchers? ?? ?? ?? ???= (PROTOCOL=TCP) (SERVICE=ynsjzzfXDB)

job_queue_processes? ?? ?= 10

hash_join_enabled? ?? ???= TRUE

background_dump_dest? ???= D:\Ora92\admin\ynsjzzf\bdump

user_dump_dest? ?? ?? ???= D:\Ora92\admin\ynsjzzf\udump

core_dump_dest? ?? ?? ???= D:\Ora92\admin\ynsjzzf\cdump

sort_area_size? ?? ?? ???= 524288

db_name? ?? ?? ?? ?? ?? ?= ynsjzzf

open_cursors? ?? ?? ?? ? = 300

star_transformation_enabled= FALSE

query_rewrite_enabled? ? = FALSE

pga_aggregate_target? ???= 209715200

aq_tm_processes? ?? ?? ? = 1

PMON started with pid=2

DBW0 started with pid=3

LGWR started with pid=4

CKPT started with pid=5

SMON started with pid=6

RECO started with pid=7

CJQ0 started with pid=8

QMN0 started with pid=9

Tue Apr 03 16:18:23 2007

starting up 1 shared server(s) ...

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

Tue Apr 03 16:18:24 2007

alter database mount exclusive

Tue Apr 03 16:18:28 2007

Successful mount of redo thread 1, with mount id 1192639056.

Tue Apr 03 16:18:28 2007

Database mounted in Exclusive Mode.

Completed: alter database mount exclusive

Tue Apr 03 16:18:28 2007

alter database open

Tue Apr 03 16:18:28 2007

Beginning crash recovery of 1 threads

Tue Apr 03 16:18:28 2007

Started first pass scan

Tue Apr 03 16:18:29 2007

Completed first pass scan

5637 redo blocks read, 156 data blocks need recovery

Tue Apr 03 16:18:29 2007

Started recovery at

Thread 1: logseq 224, block 156172, scn 0.0

Recovery of Online Redo Log: Thread 1 Group 1 Seq 224 Reading mem 0

Mem# 0 errs 0: E:\ORA92\ORADATA\YNSJZZF\REDO01.LOG

Tue Apr 03 16:18:29 2007

Ended recovery at

Thread 1: logseq 224, block 161809, scn 0.55437133

156 data blocks read, 156 data blocks written, 5637 redo blocks read

Crash recovery completed successfully

Tue Apr 03 16:18:29 2007

Thread 1 advanced to log sequence 225

Thread 1 opened at log sequence 225

Current log# 2 seq# 225 mem# 0: E:\ORA92\ORADATA\YNSJZZF\REDO02.LOG

Successful open of redo thread 1.

Tue Apr 03 16:18:29 2007

SMON: enabling cache recovery

Tue Apr 03 16:18:29 2007

Undo Segment 1 Onlined

Undo Segment 2 Onlined

Undo Segment 3 Onlined

Undo Segment 4 Onlined

Undo Segment 5 Onlined

Undo Segment 6 Onlined

Undo Segment 7 Onlined

Undo Segment 8 Onlined

Undo Segment 9 Onlined

Undo Segment 10 Onlined

Successfully onlined Undo Tablespace 1.

Tue Apr 03 16:18:29 2007

SMON: enabling tx recovery

Tue Apr 03 16:18:29 2007

Database Characterset is ZHS16GBK

replication_dependency_tracking turned off (no async multimaster replication found)

Completed: alter database open

總結

以上是生活随笔為你收集整理的mysql连接失败 ping通_哭~问：oracle 数据库有时会突然连接失败，但能ping通主机...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。