ORA-00257:archiver error解决办法

Posted 2020-08-15 园芳宝贝

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了ORA-00257:archiver error解决办法相关的知识，希望对你有一定的参考价值。

出现ORA-00257错误（空间不足错误），通过查找资料，绝大部分说这是由于归档日志太多，占用了全部的硬盘剩余空间导致的，通过简单删除日志或加大存储空间就能够解决。

(一)、oralce 11g更改归档模式、目录、日志大小（本人采用的这种做法）

一、更改Oracle为归档模式
   1.关闭oracle
SQL> shutdown immediate;
   Database closed.
   Database dismounted.
   ORACLE instance shut down.

2.启动为mount状态
SQL> startup mount

ORACLE instance started.

Total System Global Area 2572144640 bytes
Fixed Size                  2283984 bytes
Variable Size             738199088 bytes
Database Buffers         1828716544 bytes
Redo Buffers                2945024 bytes
Database mounted.

3.更改为归档模式
SQL> alter database archivelog
Database altered.
备注：‘archivelog’为归档模式；‘noarchivelog’为非归档模式。

4.更改数据库为‘打开’状态
SQL> alter database open

  5.查看归档模式信息
SQL>   archvie log list
它会提示归档的模式、是否启用、参数
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     88
Next log sequence to archive   90
Current log sequence           90

二、更改归档目录
1.查看参数db_recovery_file_dest

（1）“db_recovery_file_dest”是用于定义存储归档日志的目录。通过show parameter命令，显示参数的值为（默认为）fast_recovery_area。示例如下：

SQL> show parameter db_recovery

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string /usr/local/oracle/flash_recovery_area
db_recovery_file_dest_size           big integer 4182M

（2）查看v$recovery_file_dest视图，可得知fast_recovery_area的空间限制、已使用的空间、文件数等。

SQL> select * from v$recovery_file_dest;

NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
----------- ---------- ----------------- ---------------
D:\\oracle\\fast_recovery_area 4385144832 4346230272 2741248 102

2.更改归档日志目录
语法：alter system set 参数=值 scope=spfile;(设置成比较大的空间的目录，我这里是设置成了home下面)

示例：SQL> alter system set db_recovery_file_dest=\'/home/oracle/flash_recovery_area\' scope=spfile;

System altered.

三、更改归档日志大小

1.查看参数\'db_recovery_file_dest_size\'值
SQL> show parameter db_recov

2.更改参数\'db_recovery_file_dest_size\'值大小

SQL> alter system set db_recovery_file_dest_size=41820M scope=spfile;

System altered.

3.关闭数据库，重启数据库

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup open;
ORACLE instance started.

   4.再次查看参数\'db_recovery_file_dest_size\'值
SQL> show parameter db_reco
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string /home/oracle/flash_recovery_area
db_recovery_file_dest_size           big integer 41820M

此时重启之后，就可以了。

=========================================================================

（以下仅供参考）

(二)、百度经验的解决方案：如下（本人采用的这种做法）

解决：

1、

SecureCRT登录服务器，切换用户oracle,连接oracle

[root@userbeta~]# su - oracle

[oracle@userbeta~]$ sqlplus /nolog

SQL> connect /as sysdba

2、

检查flash recovery area的使用情况,可以看见archivelog已经很大了，达到99.94

SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;

3、

计算flash recovery area已经占用的空间

SQL> select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage;

以上是检查，可以直接设置归档文件大大小，如下：

4、

修改FLASH_RECOVERY_AREA的空间修改为6GB，修改前确认磁盘有足够空间

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=8g;

5、

现在来清理一下archivelog归档日志，生产环境建议备份

查询日志目录位置

show parameter recover;

删除归档日志,USERDB是数据库实例名

cd /u01/app/oracle/flash_recovery_area/USERDB/archivelog

使用root帐户删除该目录下的文件或者备份其它地方

6、

使用rman 操作,内容太多，只做部分截图

[oracle@userbeta archivelog]$ rman

RMAN> connect target sys/sys_passwd

crosscheck backup;

delete obsolete;

delete expired backup;

crosscheck archivelog all;

delete expired archivelog all;

//此步会有提示，输入 YES 回车

host; //退出rman

7、

确认是否操作成功

# sqlplus /nolog

SQL> connect /as sysdba

SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;

8、删除完成，重新连接数据库

ORACLE 归档日志打开关闭方法

sql> archive log list;   #查看是否是归档方式  
sql> alter system set log_archive_start=false scope=spfile; #禁用自动归档  
sql> shutdown immediate;  
sql> startup mount;    #打开控制文件，不打开数据文件  
sql> alter database noarchivelog; #将数据库切换为非归档模式  
sql> alter database open;   #将数据文件打开  
sql> archive log list;   #查看此时便处于非归档模式

bash: sqlplus: command not found 解决方法

su - oracle

vi ~/.bash_profile

在最后加上以下内容

export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db_1

export TNS_ADMIN=$ORACLE_HOME/network/admin

export PATH=.:${PATH}:$HOME/bin:$ORACLE_HOME/bin

export PATH=${PATH}:/usr/bin:/bin:/usr/bin/X11:/usr/local/bin

export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:$ORACLE_HOME/lib

export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:$ORACLE_HOME/oracm/lib

export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/lib:/usr/lib:/usr/local/lib

export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/JRE

export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/JRE/lib

export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/jlib

export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/rdbms/jlib

export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/network/jlib

export LIBPATH=${CLASSPATH}:$ORACLE_HOME/lib:$ORACLE_HOME/ctx/lib

export ORACLE_OWNER=oracle

export SPFILE_PATH=$ORACLE_HOME/dbs

export ORA_NLS10=$ORACLE_HOME/nls/data

使设置生效

source /home/oracle/.bash_profile

参考本人另一日志：

http://www.cnblogs.com/gmq-sh/p/5773374.html

Oracle shutdown immediate无法关闭数据库解决方法

在测试服务器上使用shutdown immediate命令关闭数据库时，长时间无法关闭数据库，如下所示

   1: [oracle@DB-Server admin]$ sqlplus / as sysdba

2:

   3: SQL*Plus: Release 10.2.0.4.0 - Production on Thu Nov 21 13:55:13 2013

4:

   5: Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

6:

7:

   8: Connected to:

   9: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production

  10: With the Partitioning, OLAP, Data Mining and Real Application Testing options

11:

  12: SQL> shutdown immediate;

在另外一个会话中，查看告警日志的输出结果，如下所示：告警日志信息在输出Active processes prevent shutdown operation后，就再无提示信息。

   1: [oracle@DB-Server bdump]$ tail -f 20 alert_epps.log

2:

   3: Thu Nov 21 13:55:23 2013

   4: Starting background process EMN0

   5: Shutting down instance: further logons disabled

   6: EMN0 started with pid=59, OS id=19244

   7: Thu Nov 21 13:55:24 2013

   8: Errors in file /u01/app/oracle/admin/epps/udump/epps_ora_19242.trc:

   9: ORA-04098: trigger \'ADMIN.PIND_ON_SHUT\' is invalid and failed re-validation

  10: Thu Nov 21 13:55:24 2013

  11: Shutting down instance (immediate)

  12: License high water mark = 10

  13: All dispatchers and shared servers shutdown

  14: Thu Nov 21 14:00:29 2013

  15: SHUTDOWN: Active processes prevent shutdown operation

关于SHUTDWON IMMEDIATE关闭数据库方式：

立即关闭方式(IMMEDIATE)
     立即关闭方式能够在尽可能短的时间内关闭数据库，以立即方式关闭数据库时，ORACLE将执行以下一些操作：
         *阻止任何用户建立新的连接,同时阻止当前连接的用户开始任何新的事物。
         *任何未提交的事物均被回退。
         *ORACLE不再等待用户主动断开连接，而是直接关闭、卸载数据库，并终止实例。

方法1：

此时可以通过下面命令Kill掉系统中（LOCAL＝NO）的ORACLE进程

[oracle@DB-Server ~]$ ps -ef|grep ora|grep -v grep|grep -v ora_|grep LOCAL=NO|awk \'{print $2}\'
[oracle@DB-Server ~]$ ps -ef|grep ora|grep -v grep|grep -v ora_|grep LOCAL=NO|awk \'{print $2}\'|xargs kill

此时可以顺利关闭数据库。

方法2：

使用CTRL+C取消操作，然后使用shutdown abort命令关闭数据库。当然生产环境还是慎用shutdown abort命令，使用它往往是在没有办法的情况下。因为
shutdown abort 执行后，所有正在运行的SQL语句都将立即中止。所有未提交的事务将不回滚。Oracle也不等待目前连接到数据库的用户退出系统。下一次启动数据库时需要实例恢复，因此，下一次启动可能比平时需要更多的时间。

方法3：网上比较通用的方法

1 ：首先停应用服务。
2 ：其次停止监听服务（listener）
3 ：间隔一段时间后,运行自己写的脚本去检查一下还有没有用户进程,如有, KILL.
4 ：shutdown immediate;

当然，有时候实际情况往往有些出入，例如步骤1，DBA没有应用服务器的权限。无法停止应用服务。当然也不妨碍后面步骤的执行。