Oracle体系结构-日志文件汇总

日志是数据库运行、诊断、审计和恢复的关键组成部分。

核心概念：日志的作用

日志文件的核心目的是记录数据库活动的轨迹，主要服务于：

1. 数据持久性与恢复 (Redo Log)： 确保已提交事务的更改不会因系统故障而丢失，支持实例恢复和介质恢复。
2. 变更追踪与复制 (Redo Log, Archive Log)： 捕获数据库的所有物理更改，用于逻辑或物理复制（如 Data Guard, GoldenGate）。
3. 诊断与故障排除 (Alert Log, Trace Files)： 记录数据库运行状态、错误、警告、内部事件，帮助DBA定位问题。
4. 审计与安全 (Audit Logs)： 记录用户活动，满足合规性要求，追踪可疑操作。
5. 连接与会话管理 (Listener Log)： 记录客户端连接请求、状态、失败信息。
6. 操作记录 (Alert Log)： 记录重要的管理操作（如启动、关闭、备份、恢复、参数修改）。

一、 核心日志：重做日志文件 (Redo Log Files)

• 原理：
  • 记录内容： 记录数据库中所有已提交事务产生的物理更改（数据块修改）。包括 DML (INSERT, UPDATE, DELETE)、DDL (CREATE, ALTER, DROP) 以及部分内部操作（如索引维护）。它记录的是如何重建更改（例如，“在数据文件X的块Y的偏移量Z处写入值A”），而不是SQL语句本身。
  • 目的： 确保数据库的持久性 (Durability) 和**可恢复性 (Recoverability)**。在系统崩溃（如断电）后，Oracle 使用重做日志将数据库恢复到崩溃前的一致状态（实例恢复）。在介质故障（磁盘损坏）后，结合备份和归档日志进行恢复（介质恢复）。
  • 写入机制：
    • 用户会话修改数据时，更改首先发生在数据库缓冲区缓存（内存）中。
    • 对应生成的重做记录写入**重做日志缓冲区 (Redo Log Buffer)**（内存）。
    • LGWR (Log Writer) 进程 负责将重做日志缓冲区的内容异步地、顺序地写入磁盘上的联机重做日志文件组。
    • LGWR 在以下情况触发写操作：
      • 用户提交事务 (COMMIT)。
      • 重做日志缓冲区达到 1/3 满。
      • 每 3 秒超时。
      • 在 DBWn (Database Writer) 进程将脏缓冲区写入数据文件之前（确保先记日志 Write-Ahead Logging - WAL 原则）。
      • 检查点发生时。
• 特性：
  • 循环使用 (Circular)： 数据库至少需要 2 个重做日志组（通常建议 3 个或更多）。LGWR 顺序写入当前组，写满后切换到下一个可用组（日志切换 - Log Switch）。切换时会触发检查点（Checkpoint），促使 DBWn 将相关的脏缓冲区写入数据文件。最后一个组写满后，循环回第一个组覆盖（如果第一个组已被归档）。
  • 组与成员 (Groups & Members)：
    • 组 (Group)： 逻辑概念，包含一个或多个完全相同的**成员文件 (Member File)**（镜像）。同一个组内的成员内容完全相同（冗余，提高可用性）。
    • 成员 (Member)： 物理文件。一个组至少有一个成员。
  • 大小： 需要合理设置。太小会导致频繁的日志切换和检查点，影响性能。太大会增加恢复时间。通常考虑事务量和切换频率（如 10-30 分钟切换一次）。
  • 位置： 需要高性能、高可用性的磁盘（通常与数据文件、控制文件分开存放）。
• 作用：
  • 实例恢复 (Instance Recovery)： 在数据库异常关闭（如断电）后重新启动时，Oracle 自动执行。使用当前联机重做日志中记录的、尚未写入数据文件的已提交更改（前滚 - Roll Forward）来回滚未提交的事务（回滚 - Roll Back）。
  • 介质恢复 (Media Recovery)： 当数据文件损坏或丢失时，使用备份的数据文件和应用归档日志（以及尚未归档的联机重做日志）将数据库恢复到故障点。
  • 流复制与逻辑备库 (Streams, Logical Standby)： 重做日志是捕获数据库变更的源头。
  • 增量备份： 某些备份策略依赖于重做日志或归档日志。
• 路径：
  • 路径由 CREATE DATABASE 或 ALTER DATABASE ADD LOGFILE ... 语句指定。
  • 通过视图查询：
    • SELECT GROUP#, MEMBER FROM V$LOGFILE; (显示所有成员文件路径)
    • SELECT GROUP#, STATUS, SEQUENCE#, BYTES, MEMBERS FROM V$LOG; (显示组状态和序列号)
  • 典型位置 (非绝对，取决于配置)：
    • $ORACLE_BASE/oradata/<DB_NAME>/redo<group#>_<member#>.log (传统文件系统)
    • +<DISKGROUP>/<DB_NAME>/ONLINELOG/group_<group#>.<member#> (ASM)
  • 关键参数： DB_CREATE_ONLINE_LOG_DEST_n (OMF 位置), LOG_ARCHIVE_DEST_n (归档目标，间接影响联机日志覆盖)

二、 归档日志文件 (Archive Log Files)

• 原理：
  • 生成过程： 当数据库处于 ARCHIVELOG 模式下，发生日志切换时：
    • ARCn (Archiver) 进程（默认启动一个 ARC0，可配置多个）会复制刚刚填满并被切换的联机重做日志组的内容。
    • 将这些内容保存为一个独立的、不可更改的归档日志文件（通常带有唯一的序列号）。
    • 成功归档后，该联机重做日志组才能被 LGWR 覆盖重用。
  • 目的： 保留历史的重做日志信息，用于：
    • 时间点恢复 (Point-in-Time Recovery)： 将数据库恢复到过去的任意时间点（在备份保留期内）。
    • 介质恢复： 恢复备份后创建的所有更改都记录在归档日志中。
    • 备用数据库 (Data Guard)： 物理备库持续应用主库传输过来的归档日志（或实时应用 Redo）保持同步。
• 特性：
  • 时间序列： 每个归档日志文件对应一个联机重做日志序列号，按顺序生成。
  • 不可修改： 一旦归档完成，文件内容即固定。
  • 命名格式： 可配置（通过 LOG_ARCHIVE_FORMAT 参数），通常包含线程号（RAC）、序列号等，如 %t_%s_%r.arc。
  • 保留策略： 可基于时间（RECOVERY WINDOW）或冗余数量（REDUNDANCY）配置自动删除过期的归档日志（通过 RMAN）。手动删除可能导致恢复失败。
• 作用：
  • 实现完全恢复： 是执行介质恢复（包括恢复到最新状态或过去时间点）的必要条件。
  • 支持备用数据库： Data Guard 物理备库的核心依赖。
  • 支持增量备份： RMAN 增量备份需要自上次备份以来的归档日志来应用。
  • 审计与历史分析： 通过日志挖掘工具（如 LogMiner）可以分析历史变更。
• 路径：
  • 主要配置参数：LOG_ARCHIVE_DEST_n (n=1,2,...10)，指定本地或远程（备库）的归档目标位置和属性。
  • 通过视图查询：
    • SELECT NAME, DEST_ID, STATUS FROM V$ARCHIVED_LOG; (显示归档日志文件名、目标ID、状态)
    • SHOW PARAMETER LOG_ARCHIVE_DEST_ (显示当前配置的归档目标)
  • 典型位置 (非绝对，取决于 LOG_ARCHIVE_DEST_n 配置)：
    • 本地文件系统：/u01/archivelogs/<DB_NAME>/ (例如 LOG_ARCHIVE_DEST_1='LOCATION=/u01/archivelogs')
    • ASM：+RECO/<DB_NAME>/ARCHIVELOG/ (例如 LOG_ARCHIVE_DEST_1='LOCATION=+RECO')
    • 远程备库：SERVICE=<standby_service> (通过 LOG_ARCHIVE_DEST_n 配置)
  • 关键参数： LOG_ARCHIVE_DEST_n, LOG_ARCHIVE_FORMAT, DB_RECOVERY_FILE_DEST (快速恢复区，常作为归档目标), LOG_ARCHIVE_MIN_SUCCEED_DEST (指定必须成功归档的最小目标数)。

三、 警报日志文件 (Alert Log File / Alert SID.log)

• 原理：
  • 记录内容： 一个按时间顺序记录的文本文件，包含数据库生命周期中发生的重大事件、错误、警告、状态变更、关键操作结果。
  • 写入机制： 数据库后台进程（尤其是 MMON, MMAN）和实例本身直接将重要消息写入该文件。是诊断数据库问题的首要检查点。
• 特性：
  • 纯文本： 可直接用文本编辑器（如 vi, less, tail -f）查看。
  • 持续追加： 新消息不断追加到文件末尾。文件会增长，需要定期清理或轮换（Oracle 有自动清理机制，尤其在 ADR 中）。
  • 关键信息源： 包含启动/关闭时间、检查点信息、内部错误（ORA-600）、块损坏错误（ORA-1578）、空间管理错误（ORA-165x）、参数修改记录、恢复操作记录、死锁信息等。
• 作用：
  • 实时监控： tail -f alert_<SID>.log 是监控数据库健康状态的经典方法。
  • 故障诊断： 发生问题时（如实例崩溃、性能骤降、错误频发），警报日志是查找根本原因的第一手资料。
  • 审计操作： 记录 DBA 执行的许多关键操作（如 ALTER DATABASE, ALTER SYSTEM）。
  • 跟踪数据库状态： 记录实例启动阶段、NOMOUNT/MOUNT/OPEN 状态转换信息。
• 路径 (版本差异显著)：
  • Oracle 11g 及之前 (传统路径)：
    • 由 BACKGROUND_DUMP_DEST 初始化参数指定。
    • 典型路径： $ORACLE_BASE/admin/<DB_NAME>/bdump/alert_<SID>.log
  • Oracle 11g R2 及之后 (ADR - Automatic Diagnostic Repository)：
    • 警报日志是 ADR 的一部分。
    • 路径由 DIAGNOSTIC_DEST 初始化参数决定（通常指向 $ORACLE_BASE）。
    • 标准 ADR 路径： $DIAGNOSTIC_DEST/diag/rdbms/<dbname_lowercase>/<SID>/trace/alert_<SID>.log
    • 示例： /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log
  • 查询路径方法：
    • SHOW PARAMETER BACKGROUND_DUMP_DEST (11g 及之前)
    • SHOW PARAMETER DIAGNOSTIC_DEST (11g R2 及之后)
    • SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace'; (11g R2 及之后，trace 目录，alert log 在此目录下)
    • SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Alert Log'; (11g R2 及之后，直接显示警报日志完整路径) <-- 推荐方法

四、 跟踪文件 (Trace Files)

• 原理：
  • 记录内容： 包含特定进程（服务器进程、后台进程）或会话在运行期间产生的详细诊断信息、错误堆栈、执行计划、SQL 绑定变量、等待事件、性能统计信息等。比警报日志更详细、更具体。
  • 触发方式：
    • 内部错误： 当进程遇到严重错误（如 ORA-00600, ORA-07445）时，会自动生成一个包含错误详细信息的跟踪文件。
    • 会话级跟踪： DBA 或用户可以通过 ALTER SESSION SET SQL_TRACE=TRUE; 或 DBMS_SESSION.SESSION_TRACE_ENABLE 为当前会话启用 SQL 跟踪。使用 DBMS_MONITOR 包（如 SESSION_TRACE_ENABLE）可以跟踪其他会话或模块/动作。
    • 实例级跟踪： 设置 SQL_TRACE=TRUE 在参数文件中（极度谨慎，性能影响巨大！）或动态设置 ALTER SYSTEM SET SQL_TRACE=TRUE;（同样影响大）。
    • 诊断事件： 设置特定的事件（如 EVENT="10046 trace name context forever, level 12"）会生成详细的跟踪文件（包含等待事件和绑定变量）。
    • 优化器跟踪： ALTER SESSION SET EVENTS '10053 trace name context forever, level 1'; 用于跟踪 CBO 优化器决策过程。
• 特性：
  • 纯文本或二进制： 大部分是文本（.trc），原始跟踪文件较大，通常需要工具（如 tkprof）格式化分析。部分诊断转储（如 SYSTEMSTATE）可能是二进制。
  • 按进程/会话生成： 每个进程（后台）或会话（服务器进程）在需要时生成自己独立的跟踪文件。
  • 命名规则： 通常包含实例名(SID)、进程类型（如 ora）、进程ID（如 _pmon_<pid>.trc, _<sid>_ora_<pid>.trc, _<sid>_<servicename>_<pid>.trc）。
  • 核心诊断工具： 用于深入分析性能瓶颈、死锁、内部错误、SQL 执行细节。
• 作用：
  • 深入故障诊断： 分析 ORA-00600/07445 等内部错误，查看错误堆栈和参数。
  • SQL 性能调优： 通过 SQL Trace (10046) 获取 SQL 执行统计信息（解析/执行/等待次数、时间、物理/逻辑读、行数）、执行计划、等待事件。使用 tkprof 格式化 .trc 文件生成可读报告。
  • 优化器行为分析： 通过 10053 事件跟踪理解 CBO 为何选择特定的执行计划。
  • 死锁分析： 发生死锁时，会生成包含死锁图（deadlock graph）的跟踪文件。
  • 转储内部状态： 使用 ORADEBUG 或 ALTER SYSTEM DUMP 命令生成特定结构（如控制文件、数据文件头、缓冲区缓存、SYSTEMSTATE）的转储到跟踪文件。
• 路径：
  • 后台进程跟踪文件：
    • 11g 及之前： BACKGROUND_DUMP_DEST 参数指定。
    • 11g R2 及之后 (ADR)： $DIAGNOSTIC_DEST/diag/rdbms/<dbname_lowercase>/<SID>/trace/
  • 服务器进程（用户会话）跟踪文件：
    • 11g 及之前： USER_DUMP_DEST 参数指定。
    • 11g R2 及之后 (ADR)： $DIAGNOSTIC_DEST/diag/rdbms/<dbname_lowercase>/<SID>/trace/ (与后台进程跟踪文件在同一目录)
  • 核心转储文件 (core dump)： 进程严重崩溃时生成，包含进程内存映像。
    • 11g 及之前： CORE_DUMP_DEST 参数指定（通常与 BACKGROUND_DUMP_DEST 相同）。
    • 11g R2 及之后 (ADR)： $DIAGNOSTIC_DEST/diag/rdbms/<dbname_lowercase>/<SID>/cdump/
  • 查询路径方法：
    • SHOW PARAMETER DUMP_DEST (显示 BACKGROUND, USER, CORE 的旧参数)
    • SELECT NAME, VALUE FROM V$DIAG_INFO; (11g R2 及之后，查看 Diag Trace, Diag Incident 等路径)

五、 监听器日志文件 (Listener Log File)

• 原理：
  • 记录内容： Oracle Net 监听器 (lsnrctl 进程) 的活动日志。记录客户端的连接请求、连接状态（成功/失败）、监听器启动/停止、服务注册/更新（动态注册）、拒绝的连接、负载均衡/故障转移决策等。
  • 写入机制： 监听器进程自身写入。
• 特性：
  • 纯文本： 可直接查看。
  • 持续追加： 会不断增长，需要定期轮换或清理（监听器支持日志轮换命令 lsnrctl set log_status off -> lsnrctl set log_status on）。
  • 配置相关： 日志级别、格式、轮换策略可通过 listener.ora 配置文件或 lsnrctl 命令设置。
• 作用：
  • 诊断连接问题： 当客户端无法连接到数据库时，监听器日志是首要检查点，查看连接请求是否到达监听器、为何被拒绝（如协议错误、服务名错误、权限不足、防火墙拦截）。
  • 监控连接活动： 了解哪些客户端、在什么时间、连接到了哪个服务。
  • 审计连接： 记录连接来源（IP, Hostname）。
  • 跟踪服务注册： 查看数据库实例是否成功动态注册到监听器。
• 路径：
  • 由 listener.ora 配置文件中的 LOG_FILE_<listener_name> 参数指定。如果未指定，默认使用监听器名称命名日志文件。
  • 默认位置 (常见)：
    • $ORACLE_HOME/network/log/listener.log
    • $ORACLE_BASE/diag/tnslsnr/<hostname>/listener_<name>/trace/listener.log (在配置了 ADR 的环境下，12c 及之后更常见，即使数据库未使用 ADR，监听器也可能默认使用此路径)
  • 查询路径方法：
    • lsnrctl status [listener_name] (输出中包含 Listener Log File 的路径信息)
    • 检查 listener.ora 文件 (通常在 $ORACLE_HOME/network/admin/ 或 $TNS_ADMIN 目录下) 中的 LOG_FILE_<listener_name> 参数。

六、 审计日志文件 (Audit Trail Files)

• 原理：
  • 记录内容： 根据配置的审计策略，记录用户的操作活动，以满足安全合规性要求。记录的内容包括：操作类型（如登录、登出、DDL、DML）、执行用户、执行时间、操作对象、使用的 SQL 语句、是否成功等。
  • 写入机制： 由数据库内核根据审计设置生成记录。
• 特性：
  • 存储位置：
    • 数据库审计表： 默认且推荐方式。审计记录写入 SYS.AUD$ 和 SYS.FGA_LOG$ 表（位于 SYSTEM 表空间）。可通过视图 DBA_AUDIT_TRAIL, DBA_FGA_AUDIT_TRAIL 查询。需要定期维护（清理或归档）以防止 SYSTEM 表空间耗尽。
    • 操作系统文件： 配置 AUDIT_TRAIL=OS 时，审计记录写入操作系统文件（位置由 AUDIT_FILE_DEST 指定）。文件格式是二进制，需要使用 AUDIT_FILE_DEST 或工具（如 Oracle Audit Vault）读取。
    • XML 文件： 配置 AUDIT_TRAIL=XML 或 XML, EXTENDED 时，写入 XML 文件到 AUDIT_FILE_DEST。
  • 粒度可配置： 可以审计整个数据库、特定用户、特定对象、特定语句类型、特定权限的使用等。标准审计和细粒度审计（FGA）。
  • 性能开销： 审计会带来一定的性能开销，尤其是对高频操作进行详细审计时。需要平衡安全需求和性能。
• 作用：
  • 安全合规： 满足法律法规（如 SOX, GDPR, HIPAA）和内部安全策略对数据库操作审计的要求。
  • 问责制： 追踪谁在什么时间对数据做了什么操作。
  • 入侵检测： 发现异常或恶意活动（如多次失败登录尝试、特权账户异常操作、敏感数据访问）。
  • 故障排除（安全相关）： 帮助分析安全相关的问题。
• 路径 (仅当使用 OS/XML 审计时)：
  • 操作系统文件： 由 AUDIT_FILE_DEST 初始化参数指定。
    • 典型路径： $ORACLE_BASE/admin/<DB_NAME>/adump/ (传统) 或 $DIAGNOSTIC_DEST/diag/rdbms/<dbname_lowercase>/<SID>/adump/ (ADR)。
    • 文件名通常包含 ora_<process_id>.aud 或类似格式。
  • XML 文件： 同样由 AUDIT_FILE_DEST 指定路径。
• 关键参数： AUDIT_TRAIL (取值 NONE, DB, DB_EXTENDED, OS, XML, XML_EXTENDED), AUDIT_FILE_DEST, AUDIT_SYS_OPERATIONS (是否审计以 SYSDBA/SYSOPER 连接的操作)。

七、 其他相关日志/文件

1. 控制文件 (Control File):

   • 严格来说不是日志文件，但记录了数据库的物理结构信息（数据文件、重做日志文件的位置、数据库名称、创建时间戳、检查点信息、备份元数据等）。
   • 作用： 数据库启动时读取，用于验证和定位数据文件和重做日志文件。在恢复过程中至关重要。它本身也包含一些“日志”信息（如检查点SCN、归档日志序列历史）。
   • 路径： 由 CONTROL_FILES 参数指定，通常有多个副本。通过 SELECT NAME FROM V$CONTROLFILE; 查询。

2. 闪回日志 (Flashback Logs - 如果启用了闪回数据库):

   • 原理： 当数据库启用闪回数据库 (FLASHBACK DATABASE ON) 时，DBWR 进程会将数据块在修改前的映像写入闪回日志。存储在快速恢复区（FRA）。
   • 作用： 支持将整个数据库快速回退到过去的时间点（FLASHBACK DATABASE），比传统的基于备份和恢复的时间点恢复快得多。
   • 路径： 在快速恢复区 (DB_RECOVERY_FILE_DEST) 内，由数据库自动管理。路径如 $DB_RECOVERY_FILE_DEST/<DB_NAME>/FLASHBACK/。

3. 数据泵日志 (Data Pump Export/Import Log):

   • 原理： 在执行 expdp (导出) 或 impdp (导入) 命令时，可以指定日志文件 (LOGFILE=...)。
   • 作用： 记录导出/导入作业的详细过程、状态、遇到的错误和警告。是诊断 Data Pump 作业问题的主要依据。
   • 路径： 由用户在执行命令时显式指定（通常使用目录对象）。例如：expdp ... logfile=DPUMP_DIR:expfull.log

4. Oracle Grid Infrastructure 日志 (对于 RAC/ASM):

   • 如果数据库运行在 RAC 集群或使用 ASM 存储，还会涉及大量 GI 相关的日志（CRS 日志、ASM 警报日志和跟踪文件、集群同步服务 CSS 日志、节点应用 VIP/GSD/ONS 日志等），通常位于 GI 的 ADR 路径下 ($GRID_HOME/log/<hostname>/ 或 $ORACLE_BASE/diag/crs/<hostname>/crs/)。

总结与关键视图/工具

• 视图：
  • V$LOG, V$LOGFILE (联机重做日志)
  • V$ARCHIVED_LOG, V$ARCHIVE_DEST, V$ARCHIVE_PROCESSES (归档日志)
  • V$DIAG_INFO (ADR 相关信息，包括警报日志和跟踪文件路径 - 最重要)
  • V$SESSION, V$PROCESS (结合 SQL_TRACE, 10046 事件用于生成会话跟踪)
  • DBA_AUDIT_TRAIL, DBA_FGA_AUDIT_TRAIL (数据库审计表)
  • DBA_DIRECTORIES (查看目录对象路径，用于 Data Pump 日志等)
  • V$CONTROLFILE (控制文件路径)
• 工具：
  • ADRCI (ADR Command Interpreter): 专门用于管理和查看 ADR 中的诊断信息（警报日志、跟踪文件、打包问题包 Incident Packages）。
  • TKPROF: 格式化原始的 SQL 跟踪文件 (.trc) 生成易读的性能报告。
  • Enterprise Manager (OEM): 图形化界面提供集中的日志查看、监控和告警功能。
  • LogMiner: 用于分析联机和归档重做日志文件中的内容。
  • Oradebug / ALTER SYSTEM DUMP: 生成特定内部结构的诊断转储到跟踪文件。

管理要点：

1. 监控： 定期检查警报日志 (tail -f 或 OEM)、监听器日志。监控归档日志目标空间是否充足。
2. 轮换与清理： 制定策略清理或归档旧的跟踪文件、监听器日志、审计记录（尤其是 AUD$ 表）。利用 ADR 的自动清理策略 (ADRCI> PURGE)。切勿手动删除正在使用的联机重做日志或未归档的归档日志！
3. 备份： 归档日志文件是备份策略的核心部分，必须与数据库备份一起备份并通过 RMAN 管理其保留期。
4. 位置规划： 将不同性能/可靠性要求的日志（如重做日志、归档日志、跟踪文件）放在合适的存储上（IOPS, 延迟, 冗余）。
5. 安全： 保护日志文件（尤其是审计日志）不被未授权访问或篡改。