Logfile的不同状态

本文详细解析了Oracle日志文件的不同状态,包括V$LOG和V$LOGFILE中的状态,如UNUSED、CURRENT、ACTIVE、INACTIVE、CLEARING等,并通过实例展示了日志文件状态的变化过程,帮助理解日志管理在数据库恢复中的作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转载:http://www.eygle.com/archives/2008/05/oracle_logfile.html

Logfile的不同状态

 

一、  V$LOG:STATUS 指的是GROUP的状态

 

UNUSED

尚未记录change的空白group(一般会出现在,loggroup刚刚被添加,或者刚刚使用了resetlogs打开数据库,或者使用clear logfile后)

 

CURRENT:

当前正在被LGWR使用的group(同时是ACTIVE状态)

 

ACTIVE

未被LGWR写,instance recovery需要的。还没有完成checkpoint

 

INACTIVE

online,未被LGWR写,对instance recovery不再有用了。

 

CLEARING

正在被cleargroupLog is being re-created as an empty log after an ALTER DATABASE CLEAR LOGFILE statement. After the log is cleared, the status changes to UNUSED.

 

CLEARING_CURRENT:

一个正在被clearCURRENT groupCurrent log is being cleared of a closed thread. The log can stay in this status if there is some failure in the switch such as an I/O error writing the new log header.)出现在中状态一般是有错误的。

 

二、V$LOGFILE:STATUS指的是member的状态

 

INVALID:

             不能使用的member,可能损坏了(另外,刚加入到redolog group的日志文件在被使用之前也是这个状态)

STALE

            见下面解释

DELETED

      被alter database drop logfile membermember

BLANK:

            正常的都是blank,不管是否被写。

 

下面是对metalink上对stale的解释:

 

Log files may have a status of stale regardless of redo log mirroring or

archival mode.

 

 

Solution Description:

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

 

In general, the stale status of a redo log member should not be a cause for

great concern, unless you observe that this happens frequently or

systematically.  Keep in mind that a stale log is not necessarily an invalid

log, but more of an "in-doubt" one. Once the corresponding redo group becomes

the current one again, the stale status will go away by itself.

 

 

下面是一个例子:

 

logfile中有两个filestale状态,当发生日志切换时,group1变成current状态,从而,group1下的logfile变成

blank(正常状态)

另外,这个例子也展示了logfile groupactiveinactive的变化。

当发生switch logfile前,group5current状态,switch logfile后,group5变为active状态,这说明recovery

group5是有用的,同时也说明logfile时发生的不是完全检查点。

当手工发生检查点后,group5active变为了inactive状态,此时,group5recovery不再有用。这说明:

 

alter system checkpoint发生的是完全检查点。

 

SQL> l  

  1* select * from v$logfile

SQL> /

 

    GROUP# STATUS  TYPE    MEMBER

---------- ------- ------- ----------------------------------------

         1 STALE   ONLINE  /opt/oracle/oradata/userlog2/redo01.log

         2 STALE   ONLINE  /opt/oracle/oradata/userlog2/redo02.log

         3         ONLINE  /opt/oracle/oradata/userlog2/redo03.log

         4         ONLINE  /opt/oracle/oradata/userlog2/redo04.log

         5         ONLINE  /opt/oracle/oradata/userlog2/redo05.log

 

SQL> select * from v$log;

 

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM

---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------

         1          1         21   20971520          1 NO  INACTIVE                704228 07-AUG-06

         2          1         22   20971520          1 NO  INACTIVE                753376 07-AUG-06

         3          1         23   20971520          1 NO  INACTIVE                785843 07-AUG-06

         4          1         24   20971520          1 NO  INACTIVE                868923 08-AUG-06

         5          1         25   20971520          1 NO  CURRENT                 951980 10-AUG-06

 

SQL> alter system switch logfile;

 

System altered.

 

SQL> select * from v$logfile;

 

    GROUP# STATUS  TYPE    MEMBER

---------- ------- ------- ----------------------------------------

         1         ONLINE  /opt/oracle/oradata/userlog2/redo01.log

         2 STALE   ONLINE  /opt/oracle/oradata/userlog2/redo02.log

         3         ONLINE  /opt/oracle/oradata/userlog2/redo03.log

         4         ONLINE  /opt/oracle/oradata/userlog2/redo04.log

         5         ONLINE  /opt/oracle/oradata/userlog2/redo05.log

 

SQL> select * from v$log;

 

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM

---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------

         1          1         26   20971520          1 NO  CURRENT                 994126 10-AUG-06

         2          1         22   20971520          1 NO  INACTIVE                753376 07-AUG-06

         3          1         23   20971520          1 NO  INACTIVE                785843 07-AUG-06

         4          1         24   20971520          1 NO  INACTIVE                868923 08-AUG-06

         5          1         25   20971520          1 NO  ACTIVE                  951980 10-AUG-06

 

SQL>

SQL> alter system checkpoint;

 

System altered.

 

SQL> select * from v$log;

 

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM

---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------

         1          1         26   20971520          1 NO  CURRENT                 994126 10-AUG-06

         2          1         22   20971520          1 NO  INACTIVE                753376 07-AUG-06

         3          1         23   20971520          1 NO  INACTIVE                785843 07-AUG-06

         4          1         24   20971520          1 NO  INACTIVE                868923 08-AUG-06

         5          1         25   20971520          1 NO  INACTIVE                951980 10-AUG-06


<think>好的,我现在需要帮助用户解决关于Redis日志文件配置和使用的问题。首先,用户提到了几个引用内容,我需要先仔细阅读这些引用,确保回答准确。 引用[1]指出日志路径是"/var/log/redis/redis-server.log",并且提到默认有16个数据库。引用[3]和[4]都提到了配置文件中logfile的配置项,以及如何找到和修改它。引用[2]则涉及如何启动Redis服务,这可能与日志生成有关。 首先,我应该先整理配置logfile的步骤。根据引用[3]和[4],用户需要编辑redis.conf文件,找到logfile配置项,并设置路径。默认可能是空或者注释掉的,所以需要取消注释并指定路径,比如/var/log/redis/redis-server.log。同时,要注意目录权限,确保Redis有写入权限,这点用户可能会忽略,需要提醒。 然后,关于日志级别的配置,引用[4]提到loglevel和logfile相关,所以需要说明loglevel的四个级别,并建议使用notice级别,这可能是默认值,但用户可能需要调整。 接下来,配置完成后如何启动Redis?引用[2]给出了启动命令,即./src/redis-server redis.conf,需要强调必须在Redis目录下执行,否则路径可能不正确。同时,如果修改了配置文件,重启服务才能生效,这点也很重要。 日志轮转部分,用户可能不知道如何管理日志文件过大,需要提到常用的logrotate工具,并给出配置示例,比如按天切割、保留7天等。这部分虽然引用中没有直接提到,但属于常见做法,可以补充说明。 验证配置是否生效,用户可能需要检查日志文件是否存在,或者用tail命令实时查看日志输出,这能帮助确认配置正确。 可能的问题点:用户可能遇到权限问题,比如指定的日志目录Redis没有写入权限,导致服务启动失败。或者配置后忘记重启Redis,导致配置未生效。此外,logrotate配置是否正确也会影响日志管理。 最后,生成相关问题需要考虑用户可能进一步想知道的内容,比如日志级别有哪些、如何调试、权限问题、日志分析工具等。这些都需要涵盖,以帮助用户全面了解。</think>### Redis日志文件配置与使用指南 #### 一、日志文件配置步骤 1. **配置文件路径** Redis的日志文件通过`redis.conf`配置文件中的`logfile`参数定义,默认路径通常为`/var/log/redis/redis-server.log`[^1]。需确保Redis进程对目标目录有写入权限。 2. **编辑配置文件** - 找到`logfile`配置项(通常与`loglevel`相邻): ```bash logfile "/var/log/redis/redis-server.log" ``` - 若路径为空或注释状态,取消注释并填写自定义路径[^3][^4]。 3. **日志级别控制** 通过`loglevel`设置日志详细程度,可选值包括: - `debug`(调试信息) - `verbose`(详细信息) - `notice`(默认,生产环境推荐) - `warning`(仅关键警告) 4. **启动Redis服务** 使用以下命令加载配置并启动服务: ```bash ./src/redis-server redis.conf # 需在Redis安装目录执行[^2] ``` --- #### 二、日志文件管理 1. **日志轮转(Log Rotation)** 推荐使用`logrotate`工具管理日志文件,避免单文件过大。示例配置: ```conf /var/log/redis/redis-server.log { daily rotate 7 compress missingok notifempty create 640 redis redis } ``` 2. **实时查看日志** 通过`tail`命令监控日志动态: ```bash tail -f /var/log/redis/redis-server.log ``` --- #### 三、常见问题排查 1. **权限问题** 若日志文件未生成,检查目录权限: ```bash chown redis:redis /var/log/redis/ chmod 755 /var/log/redis/ ``` 2. **配置未生效** 修改配置后需重启Redis服务: ```bash ./src/redis-cli shutdown # 先停止服务 ./src/redis-server redis.conf # 重新启动 ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值