ORA-16038: log 3 sequence# 103 cannot be archived

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: [size=large]今天在自己机器做了个实验,插入10万条,由于空间少,重启数据库时出现: [size=x-large]SQL> startup ORACLE instance started.

[size=large]今天在自己机器做了个实验,插入10万条,由于空间少,重启数据库时出现: 

[size=x-large]SQL> startup 
ORACLE instance started. 

Total System Global Area  188743680 bytes 
Fixed Size                  1218460 bytes 
Variable Size             167774308 bytes 
Database Buffers           16777216 bytes 
Redo Buffers                2973696 bytes 
Database mounted. 
ORA-16038: log 3 sequence# 103 cannot be archived 
ORA-19502: write error on file "", blockno  (blocksize=) 
ORA-00312: online log 3 thread 1: '/home/lc_orauser/oradata/niutest/redo03.log' 


后来发现是 闪回区的空间被全部占用 

select group#,sequence#,archived,status from v$log; 

    GROUP#  SEQUENCE# ARC STATUS 
---------- ---------- --- ---------------- 
         1        104 NO  INACTIVE 
         3        103 NO  INACTIVE 
         2        105 NO  CURRENT 


--1、清空闪回区空间,根据查询视图v$log可知,当前活动日志为2号日志组,则此时需要清空3号日志组的, 

alter database clear unarchived logfile group 3; 

然后再 

alter database open; 

解决了。 

--2、增大db_recovery_file_dest_size的值 

SQL> show parameter db_recovery 
NAME                                 TYPE        VALUE 
------------------------------------ ----------- ------------------------------ 
db_recovery_file_dest                string      D:/oracle/product/10.2.0/flash_recovery_area 
db_recovery_file_dest_size           big integer 2G 
SQL> alter system set db_recovery_file_dest_size=3G scope=both; 
系统已更改。 
SQL> alter database open; 
数据库已更改。 

为什么会出现这种情况呢? 

(1).检查flash recovery area的使用情况: 
SQL> select * from v$flash_recovery_area_usage; 
FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES 
------------ ------------------ ------------------------- --------------- 
CONTROLFILE                   0                         0               0 
ONLINELOG                     0                         0               0 
ARCHIVELOG                 6.36                         0               4 
BACKUPPIECE                 .22                         0               1 
IMAGECOPY                 63.68                         0               5 
FLASHBACKLOG                .51                       .25               2 
已选择6行。 
SQL> 
(2).计算flash recovery area已经占用的空间: 
SQL> select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage; 
SUM(PERCENT_SPACE_USED)*3/100 
----------------------------- 
                       2.1231 
可以看到,这里已经有2.1231G使用了,这说明我们刚开始设置的db_recovery_file_dest_size=2G不足,导致online redo log无法归档,在这里,我们通过设置db_recovery_file_dest_size参数,增大了flash recovery area来解决这个问题。 
(3).也可以通过删除flash recovery area中不必要的备份来释放flash recovery area空间来解决这个问题: 
      (1). delete obsolete; 
      (2). crosscheck backupset; 
             delete expired backupset;[/size][/size]

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
21天前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
139 3
|
3月前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
119 3
|
22天前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1585 14
|
17天前
|
Python
log日志学习
【10月更文挑战第9天】 python处理log打印模块log的使用和介绍
20 0
|
19天前
|
数据可视化
Tensorboard可视化学习笔记(一):如何可视化通过网页查看log日志
关于如何使用TensorBoard进行数据可视化的教程,包括TensorBoard的安装、配置环境变量、将数据写入TensorBoard、启动TensorBoard以及如何通过网页查看日志文件。
92 0
|
22天前
|
存储 分布式计算 NoSQL
大数据-136 - ClickHouse 集群 表引擎详解1 - 日志、Log、Memory、Merge
大数据-136 - ClickHouse 集群 表引擎详解1 - 日志、Log、Memory、Merge
24 0
|
22天前
|
缓存 Linux 编译器
【C++】CentOS环境搭建-安装log4cplus日志组件包及报错解决方案
通过上述步骤,您应该能够在CentOS环境中成功安装并使用log4cplus日志组件。面对任何安装或使用过程中出现的问题,仔细检查错误信息,对照提供的解决方案进行调整,通常都能找到合适的解决之道。log4cplus的强大功能将为您的项目提供灵活、高效的日志管理方案,助力软件开发与维护。
44 0
|
2月前
|
Java
日志框架log4j打印异常堆栈信息携带traceId,方便接口异常排查
日常项目运行日志,异常栈打印是不带traceId,导致排查问题查找异常栈很麻烦。
|
2月前
|
存储 监控 数据可视化
SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
【9月更文挑战第2天】SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
123 9