企业官网建设流程全解析

北京专业建设网站公司哪家好,网站建设一年600,网站建设国际标准,抖音直播开放平台起因 周日凌晨四点多#xff0c;被两个告警短信惊醒#xff01;拿起来一看是ORA-04031的告警#xff0c;内存溢出了#xff1f;OOM了是大问题呀#xff0c;赶紧起来查看#xff01;但是经过一番查看#xff0c;并没有问题#xff1f;什么情况难道是误报了#xff1f;…起因周日凌晨四点多被两个告警短信惊醒拿起来一看是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 informationPatch Id: 19769480Patch Description: Database Patch Set Update : 12.1.0.2.2 (19769480)Patch Apply Time: 2015-03-05 11:08:50 GMT01: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