对ora-16032和ORA-09291报错的疑惑

tsx197

OS：window server 2003
DB： oracle 10.2.0.1
报错：ORA-16032: parameter LOG_ARCHIVE_DEST destination string cannot be translated
            ORA-09291: sksachk: invalid device specified for archive destination
            OSD-04018: Ξ???？？????？?？??？????
            O/S-Error: (OS 123) ？??？??？？？???？？????？？?
问题描述：在alter日志中没找到相关详细的报错，尤其是对乱码部分的描述。关DB时用的shutdown immediate,开数据库用start、 start mount、 start nomount均报上面相同的错。昨天有同事整理过服务器上文件。

tsx197

没开归档，还生没设置过LOG_ARCHIVE_DEST
SQL> conn / as sysdba
已连接。
SQL> archive log list;
数据库日志模式             非存档模式
自动存档             禁用
存档终点            USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列     29764
当前日志序列           29766

Maclean Liu(刘相兵

没有看到 alert.log 中与 LOG_ARCHIVE_DEST  相关的信息

你是否在手动设置 LOG_ARCHIVE_DEST  ， 命令是什么 ， 不要家牙膏式的问答！

tsx197

Starting background process EMN0
EMN0 started with pid=62, OS id=3400
Tue Jun 26 10:28:18 2012
Shutting down instance: further logons disabled
Tue Jun 26 10:28:28 2012
Stopping background process QMNC
Tue Jun 26 10:28:29 2012
Stopping background process CJQ0
Tue Jun 26 10:28:30 2012
Stopping background process MMNL
Tue Jun 26 10:28:31 2012
Stopping background process MMON
Tue Jun 26 10:28:32 2012
Shutting down instance (immediate)
License high water mark = 68
Tue Jun 26 10:28:32 2012
Stopping Job queue slave processes
Tue Jun 26 10:28:32 2012
Job queue slave processes stopped
All dispatchers and shared servers shutdown
Tue Jun 26 10:28:43 2012
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
Tue Jun 26 10:28:46 2012
ALTER DATABASE CLOSE NORMAL
Tue Jun 26 10:28:47 2012
SMON: disabling tx recovery
SMON: disabling cache recovery
Tue Jun 26 10:28:47 2012
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Thread 1 closed at log sequence 29744
Successful close of redo thread 1
Tue Jun 26 10:28:48 2012
Completed: ALTER DATABASE CLOSE NORMAL
Tue Jun 26 10:28:48 2012
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
Tue Jun 26 10:30:22 2012
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Tue Jun 26 10:31:13 2012
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Tue Jun 26 10:31:52 2012
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Tue Jun 26 10:43:52 2012
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Tue Jun 26 11:06:24 2012
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =61
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.1.0.
System parameters with non-default values:
  processes                = 500
  sessions                 = 555
  nls_language             = SIMPLIFIED CHINESE
  nls_territory            = CHINA
  sga_target               = 935329792
  control_files            = D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\CONTROL01.CTL, D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\CONTROL02.CTL, D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\CONTROL03.CTL
  db_block_size            = 8192
  compatible               = 10.2.0.1.0
  db_file_multiblock_read_count= 16
  db_recovery_file_dest    = d:\oracle\product\10.2.0/flash_recovery_area
  db_recovery_file_dest_size= 2147483648
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  remote_login_passwordfile= EXCLUSIVE
  db_domain                =
  dispatchers              = (PROTOCOL=TCP) (SERVICE=TESTXDB)
  job_queue_processes      = 10
  audit_file_dest          = D:\ORACLE\PRODUCT\10.2.0\ADMIN\TEST\ADUMP
  background_dump_dest     = D:\ORACLE\PRODUCT\10.2.0\ADMIN\TEST\BDUMP
  user_dump_dest           = D:\ORACLE\PRODUCT\10.2.0\ADMIN\TEST\UDUMP
  core_dump_dest           = D:\ORACLE\PRODUCT\10.2.0\ADMIN\TEST\CDUMP
  db_name                  = TEST
  open_cursors             = 300
  pga_aggregate_target     = 311427072
PMON started with pid=2, OS id=1476
PSP0 started with pid=5, OS id=1792
MMAN started with pid=8, OS id=6092
DBW0 started with pid=11, OS id=224
DBW1 started with pid=14, OS id=1500
DBW2 started with pid=17, OS id=4808
LGWR started with pid=20, OS id=3820
CKPT started with pid=23, OS id=5832
Tue Jun 26 11:06:24 2012
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=38, OS id=1080
Tue Jun 26 11:06:24 2012
starting up 1 shared server(s) ...
Tue Jun 26 11:06:25 2012
ALTER DATABASE   MOUNT
SMON started with pid=26, OS id=4468
MMON started with pid=35, OS id=1348
RECO started with pid=29, OS id=4072
CJQ0 started with pid=32, OS id=3384
Tue Jun 26 11:06:29 2012
Setting recovery target incarnation to 2
Tue Jun 26 11:06:29 2012
Successful mount of redo thread 1, with mount id 4093011377
Tue Jun 26 11:06:29 2012
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Tue Jun 26 11:06:29 2012
ALTER DATABASE OPEN
Tue Jun 26 11:06:29 2012
Thread 1 opened at log sequence 29744
  Current log# 1 seq# 29744 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO01.LOG
Successful open of redo thread 1
Tue Jun 26 11:06:29 2012
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Tue Jun 26 11:06:29 2012
SMON: enabling cache recovery
Tue Jun 26 11:06:30 2012
Successfully onlined Undo Tablespace 1.
Tue Jun 26 11:06:30 2012
SMON: enabling tx recovery
Tue Jun 26 11:06:30 2012
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=50, OS id=3912
Tue Jun 26 11:06:32 2012
db_recovery_file_dest_size of 2048 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.
Tue Jun 26 11:06:33 2012
Completed: ALTER DATABASE OPEN
Tue Jun 26 11:08:32 2012
Memory Notification: Library Cache Object loaded into SGA
Heap size 2320K exceeds notification threshold (2048K)
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw==

Tue Jun 26 11:12:21 2012
Thread 1 advanced to log sequence 29745
  Current log# 2 seq# 29745 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO02.LOG
Tue Jun 26 11:16:44 2012
Thread 1 advanced to log sequence 29746
  Current log# 3 seq# 29746 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO03.LOG
Tue Jun 26 11:21:16 2012
Thread 1 advanced to log sequence 29747
  Current log# 1 seq# 29747 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO01.LOG
Tue Jun 26 11:24:32 2012
Thread 1 advanced to log sequence 29748
  Current log# 2 seq# 29748 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO02.LOG
Tue Jun 26 11:27:46 2012
Thread 1 advanced to log sequence 29749
  Current log# 3 seq# 29749 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO03.LOG
Tue Jun 26 11:30:34 2012
Thread 1 advanced to log sequence 29750
  Current log# 1 seq# 29750 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO01.LOG
Tue Jun 26 11:35:31 2012
Thread 1 advanced to log sequence 29751
  Current log# 2 seq# 29751 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO02.LOG
Tue Jun 26 11:38:41 2012
Thread 1 advanced to log sequence 29752
  Current log# 3 seq# 29752 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO03.LOG
Tue Jun 26 11:42:32 2012
Thread 1 advanced to log sequence 29753
  Current log# 1 seq# 29753 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO01.LOG
Tue Jun 26 11:45:51 2012
Thread 1 advanced to log sequence 29754
  Current log# 2 seq# 29754 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO02.LOG
Tue Jun 26 11:49:58 2012
Thread 1 advanced to log sequence 29755
  Current log# 3 seq# 29755 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO03.LOG
Tue Jun 26 11:52:59 2012
Thread 1 advanced to log sequence 29756
  Current log# 1 seq# 29756 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO01.LOG
Tue Jun 26 11:57:25 2012
Thread 1 advanced to log sequence 29757
  Current log# 2 seq# 29757 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO02.LOG
Tue Jun 26 12:01:10 2012
Thread 1 advanced to log sequence 29758
  Current log# 3 seq# 29758 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO03.LOG
Tue Jun 26 12:02:28 2012
Thread 1 cannot allocate new log, sequence 29759
Checkpoint not complete
  Current log# 3 seq# 29758 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO03.LOG
Thread 1 advanced to log sequence 29759
  Current log# 1 seq# 29759 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO01.LOG

tsx197

不会上传，只好把今天从重启开始的都贴出来了，还请刘大多包涵着些看.

[ 本帖最后由 tsx197 于 2012-6-26 12:15 编辑 ]

tsx197

啊，刘大，你回的太快了。我还没写完。。。

tsx197

看到报错，我认为是启动DB时spfile中指定了归档地址，但是它找不到。打算：
法1：想办法找回原来的归档文件还原
法2：新建一个归档地址，修改参数文件后再启动
考虑到公司规定在处理时长和操作上都要跟领导汇报，同意后方可操作，所以向上级申请操作。他直接操作了。。。。。。。办法很乖张（还是不得不佩服，起码在短时间内让应用可用了），是覆盖了现有的init.ora,然后重新用pfile创建spfile来启动。
发这贴子的问题来了：他表示不是归档日志找不到，而是spfile文件损坏导致，我的判断从根源上就出错了。我不否认他的处理方法上比我直接，在应用中更适用，是值得我学习的。可我的判断应该没错吧，而且我的解决方案也没问题吧，只是效率上没他的高，但更安全啊。万一在安装DB后还做了什么参数修改咧，他这样做不是很危险？

Maclean Liu(刘相兵

请上传完整的alert.log