ORA-01033错误解决方案

现象：SQL*Plus无法连接，显示以下错误： ORA-01033 : ORACLE initialization or shutdown in progress 

分析：应该是Oracle在启动后，用户登录时是要将方案中原有配置信息装载进入，装载过程中遇到原有文件指定的位置上没有找到，所以就报出错误。

解决过程：
以DBA用户登录，具体命令是
sqlplus /NOLOG
>connect sysdba/sysdba as sysdba
提示：已成功

>shutdown normal
(等了半天没有停掉)
于是执行

>shutdown immediate
提示：数据库已经关闭已经卸载数据库 ORACLE 例程已经关闭

>startup mount
提示：ORACLE例程已经启动
Total System Global Area 118255568 bytes Fixed Size
282576 bytes Variable Size
82886080 bytes Database Buffers
33554432 bytes Redo Buffers
532480 bytes
数据库装载完毕

>alter database

---

错误描述：

ORA-16038: log 2 sequence# 344 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 2 thread 1: 'E:ORACLEORADBBKCYUNWHREDO02.LOG'

>sqlplus / as sysdba

SQL> select open_mode from v$database;

OPEN_MODE
----------
MOUNTED

SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-16014: 日志 1 的序列号 317 未归档, 没有可用的目的地
ORA-00312: 联机日志 1 线程 1:
'E:ORACLEPRODUCT10.2.0ORADATAORACLEREDO01.LOG'

解决方法：

1.将归档设置到其他目录，修改alter system set log_archive_dest = 其他路径

2.转移或者删除闪回恢复区里的归档日志。

3.增大闪回恢复区。
ALTER SYSTEM SET db_recovery_file_dest_size=4g scope=both;

这里解析一下第三种情况

我的处理方法是采用第3种方法,下边是我的操作过程：

SQL> show parameter db_recovery_file_dest_size;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest_size           big integer 2G
SQL> alter system set db_recovery_file_dest_size=3G;

系统已更改。

SQL> alter database open;

数据库已更改。

SQL> show parameter db_recovery_file_dest_size;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest_size           big integer 3G
SQL>

以上操作之后，说明档路径下的可用空间扩充变为3G了。

也许会有人提出疑问，“那我把原来已经形成的2G归档日志删除掉，oracle database不就能用3G了么？”其实不是这样，虽然在物理空间上，已经删除了2G,但是动态性能视图（v$recovery_file_dest) 并没有释放此这2g空间，可以使用select * from v$recovery_file_dest 查询出来。若你不从动态性能视图里删除这2G的空间，oracle database会认为这2G依然被占用。若是有个大的事物提交，并有频繁的日志切换，1G的空间马上就被用完，到时候你的 alert_oracle.log就有错误出现，比如，
ORA-19815: WARNING: db_recovery_file_dest_size of 3221225472 bytes is 100.00% used, and has 0 remaining bytes available.

也就是说，归档日志空间不够用了，不能采用直接删除物理上真实的文件来解决，还是需要把动态性能视图里的数据更改一下。

采用RMAN 来修改归档日志。

>RMAN TARGET SYS/sysadmin@orcl

--查看归档日志的状态

RMAN> list archivelog all;

--手工删除归档日志文件

RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';

或者

1.是RMAN>  crosscheck archivelog all;--此命令的含义是检查所有归档日志的状态，并把遗失的标记为expired，也就是说，expired 表示已经被操作系统中被删除的归档日志。
2.是delete expired archivelog all; --此命令的含义是删除expired的归档日志