阜阳市网站建设_网站建设公司_过渡效果_seo优化

起因

周日凌晨四点多，被两个告警短信惊醒！拿起来一看是ORA-04031的告警，内存溢出了？OOM了是大问题呀，赶紧起来查看！但是经过一番查看，并没有问题？什么情况难道是误报了？

经过查看原来是alert log输出了“启动信息”，同时启动信息中有一个ORA-04031相关的oneoff 补丁，被alert log日志监控给捕获，导致误告警！ 但是数据库并发生重启，为什么会在alertlog中输出启动信息呢？这里就是提到一下12C+的一个小特性，会在特定的情况下即使没有发生重启也会打印启动和patch信息等。

下面，我们来详细聊聊这个特性，以及它背后的原理和注意事项。问题的表象：警报日志中“伪重启”信息想象一下，你在检查警报日志时，看到类似这样的内

Mon Aug 24 13:55:50 2015Archived Log entry 591 added for thread 1 sequence 287 ID 0x3ad9706d dest 1: <-- 正常归档日志行为Mon Aug 24 13:55:52 2015Thread 1 cannot allocate new log, sequence 289 <-- 检查点未完成，但不是问题核心Checkpoint not completeCreating new log segment: -->这个是一个明细标志Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production <-- 数据库版本横幅，看起来像启动信息With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,Advanced Analytics and Real Application Testing options.ORACLE_HOME = /opt/oracle/product/12.1.0System name: LinuxNode name: xxxxxxxxx.xxxxx.xxxRelease: 2.6.32-504.12.2.el6.x86_64Version:#1SMP Sun Feb 1 12:14:02 EST 2015Machine: x86_64Using parameter settings in client-side pfileSystem parameters with non-default values:processes = 2000sessions = 3024...===========================================================Dumping current patch information===========================================================Patch Id: 19769480Patch Description: Database Patch Set Update : 12.1.0.2.2 (19769480)Patch Apply Time: 2015-03-05 11:08:50 GMT+01:00...Mon Aug 24 13:55:53 2015Thread 1 advanced to log sequence 289 (LGWR switch) <-- 正常日志切换，继续运行

这些信息通常出现在真正的数据库启动时，包括版本详情、参数设置和补丁列表。但在这里，你会注意到日志前后时间戳非常接近（比如从13:55:52到13:55:53，只相差一秒），而且没有任何关机消息或错误条件提示。如果这是真正的意外重启，时间戳间隙会更明显，通常不会是亚秒级。

背后的原因：

Oracle 12c的新日志分段机制这其实是Oracle从12c版本开始引入的一个新行为，在11.2.0.4或更早版本中不会出现。Oracle数据库的警报日志有两种格式：传统的文本文件（alert.log）和XML格式的文件（log.xml）。XML格式的日志文件用于更结构化的记录和查询，但它有一个大小限制——默认10MB。当log.xml文件达到10MB大小时，Oracle会自动进行“分段”（segmentation）操作：

• 系统会将当前log.xml重命名为log_<n>.xml（其中<n>是一个递增的数字，比如log_1.xml、log_2.xml等）。

• 然后创建一个新的log.xml文件，继续记录后续日志。
• 在这个分段过程中，Oracle会向文本警报日志（alert.log）中转储一些“启动式”信息，包括：
  • 数据库版本横幅。
  • 非默认系统参数列表。
  • 当前补丁信息的完整转储。

这个过程是完全自动的，且不中断数据库的正常运行。日志前后会继续显示正常的活动，比如日志切换（LGWR switch）或归档操作，没有任何致命错误或崩溃迹象。简单来说，这只是日志文件的管理机制，不是数据库重启。为什么Oracle要这么设计？主要是为了防止单个日志文件无限膨胀，导致存储问题或查询性能下降。通过分段，旧日志被归档，新日志从头开始，保持文件大小可控。同时，转储参数和补丁信息可以帮助运维人员快速了解当前数据库配置，即使在查看分段后的日志时也能一目了然。如何确认这不是重启？

• 检查时间戳：如果前后日志时间戳几乎无缝连接（比如几秒内），且没有关机或错误消息，那就是分段行为。如果是真正重启，通常会有明显的时差或重启日志。
• 查看日志上下文：分段前后的日志会继续正常活动，没有“Starting ORACLE instance”之类的明确重启指示。
• 对比旧版本：在11g或更早版本，这种行为不会发生。如果你从旧版本升级到12c，可能会第一次遇到这个“惊喜”。

潜在问题和注意事项虽然这个特性是正常的，但如果你的系统生成大量日志消息，它可能会成为一个小麻烦。例如：

• 如果启用补充日志（supplemental logging）并使用LogMiner等工具，log.xml可能会每几分钟就达到10MB，导致频繁分段。
• 结果是alert.log中充斥着重复的参数和补丁信息，文件快速膨胀，阅读起来不方便。

Oracle曾收到过相关增强请求，比如Bug 21326339（“CURRENT PROCESS FOR SEGMENTING LOG.XML CAUSES PROBLEMS”），希望优化这个过程。但这个请求被拒绝了，因为Oracle已经提供了下划线参数（underscore parameters）来控制分段时转储的信息量。你可以咨询Oracle支持或文档，调整这些参数来减少重复输出（注意：修改下划线参数需谨慎，通常需要Oracle指导）。如果日志生成确实过多，建议检查系统是否在高负载下产生过多警告或调试信息，优化配置以减少不必要的日志。 了解这个特性 无需惊慌 看到警报日志中突然冒出的“启动信息”，别急着以为数据库重启了——这很可能只是Oracle 12c+在归档切换XML日志文件。确认上下文后，你会发现数据库一切正常，没有任何错误条件。理解这个特性，能帮你节省不少排查时间。

参考文档：KB72608 -12c Alert Log Appears To Show Unexpected Instance Restart