[20170407]关于增量检查点的一个疑问.txt

简介: [20170407]关于增量检查点的一个疑问.txt --//oracle现在写脏块基本采用增量检查点,除非执行alter system checkpoint,或者shutdown immediate(normal)正常关闭数据库.

[20170407]关于增量检查点的一个疑问.txt

--//oracle现在写脏块基本采用增量检查点,除非执行alter system checkpoint,或者shutdown immediate(normal)正常关闭数据库.
--//别人的疑问,如果如果写增量检查点时,current log tail at RBA=Incremental checkpoint up to RBA时,如下情况

1.环境:
SYS@book> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SYS@book> alter system set log_checkpoints_to_alert=true scope=memory;
System altered.

SYS@book> alter system set log_checkpoint_timeout=120 scope=memory;
System altered.
--//这样设置出现current log tail at RBA=Incremental checkpoint up to RBA概率大一些.
--//检查alert.

Incremental checkpoint up to RBA [0x31a.c823.0], current log tail at RBA [0x31a.c823.0]
Fri Apr 07 15:38:00 2017

--//这时查看视图x$kcccp:
column on_disk_rba16 format a20
column rtckp_rba format a20
column diff_date format 999999.99
column CPOSD_ono_disk_rba_scn format 99999999999999999999999999999999
column cpdrt heading "检查点队列|脏块数量|CPDRT"
column cpodt_on_disk_rba heading "检查点队列|on disk rba|时间戳|CPODT"
column cpods heading "检查点队列|on disk rba scn|CPODS"
column cphbt heading "检查点心跳|CPHBT"
column current_sysdate heading "当前时间|SYSDATE"

PROMPT
PROMPT REDO ( Hexadecimal ):
PROMPT

SELECT cpdrt ,
       '0x'||to_char(cplrba_seq,'FMxxxxxxxx') || '.' || to_char(cplrba_bno,'FMxxxxxxxx')|| '.' || to_char(cplrba_bof,'FMxxxx') "low_rba16",
       '0x'||to_char(cpodr_seq,'FMxxxxxxxx') || '.' || to_char(cpodr_bno,'FMxxxxxxxx') || '.' || to_char(cpodr_bof,'FMxxxx') "on_disk_rba16",
       TO_DATE (CPODT, 'MM-DD-YYYY HH24:MI:SS') cpodt_on_disk_rba,
       SYSDATE current_sysdate,
       ROUND ( (SYSDATE - TO_DATE (CPODT, 'MM-DD-YYYY HH24:MI:SS')) * 86400,
              2)
          diff_date,
       CPODS ,
           CPHBT,
       current_scn,
       current_scn - cpods diff_scn,
       indx
  FROM x$kcccp, v$database
WHERE CPLRBA_SEQ <> 0;

SYS@book> @ &r/checkpoint
REDO ( Hexadecimal ):
                                                       检查点队列
  检查点队列                                           on disk rba                                        检查点队列
    脏块数量                                           时间戳              当前时间                       on disk rba scn    检查点心跳
       CPDRT low_rba16            on_disk_rba16        CPODT               SYSDATE              DIFF_DATE CPODS                   CPHBT  CURRENT_SCN     DIFF_SCN         INDX
------------ -------------------- -------------------- ------------------- ------------------- ---------- ---------------- ------------ ------------ ------------ ------------
           0 0xffffffff.ffffffff. 0x31a.c838.0         2017-04-07 15:37:59 2017-04-07 15:38:46      47.00 13277192191         940697982            0 -13277192191            0
             ffff

--//low_rba = 0xffffffff.ffffffff.ffff.如果这时异常关闭数据库会出现什么情况呢?oracle如何确定恢复的起点呢low_rba ? (这也
--//是别人问的问题)
--//执行shutdown abort,再重新启动数据库,观察alrt文件:

Fri Apr 07 15:39:24 2017
alter database open
Beginning crash recovery of 1 threads
parallel recovery started with 23 processes
Started redo scan
Completed redo scan
read 0 KB redo, 0 data blocks need recovery
Started redo application at
Thread 1: logseq 794, block 51256, scn 13277192191
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Recovery of Online Redo Log: Thread 1 Group 1 Seq 794 Reading mem 0
  Mem# 0: /mnt/ramdisk/book/redo01.log
Completed redo application of 0.00MB
Completed crash recovery at
Thread 1: logseq 794, block 51257, scn 13277212192
0 data blocks read, 0 data blocks written, 0 redo k-bytes read
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fri Apr 07 15:39:25 2017
LGWR: STARTING ARCH PROCESSES
Fri Apr 07 15:39:25 2017
ARC0 started with pid=45, OS id=21810
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thread 1 advanced to log sequence 795 (thread open)
Thread 1 opened at log sequence 795
  Current log# 2 seq# 795 mem# 0: /mnt/ramdisk/book/redo02.log
Successful open of redo thread 1

--//0x31a = 794
--//0xc838 = 51256
--//正好是on_disk_rba地址.注意看下划线内容.

--//噢明白了.如果出现这样的情况,不需要恢复.
--//实际上如果出现脏块,仅仅将low_rba16设置为当前的on_disk_rba16.以这个作为异常恢复的起点.
--//简单写一个例子:
]$ cat a.sql
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
@ &r/checkpoint
update scott.t1 set object_name=object_name where rownum<100 ;
commit;
host sleep 3
@ &r/checkpoint
--//很奇怪,必须加入sleep 3,然后看不到变化.

--//结果如下:
REDO ( Hexadecimal ):

                                                       检查点队列
  检查点队列                                           on disk rba                                        检查点队列
    脏块数量                                           时间戳              当前时间                       on disk rba scn    检查点心跳
       CPDRT low_rba16            on_disk_rba16        CPODT               SYSDATE              DIFF_DATE CPODS                   CPHBT  CURRENT_SCN     DIFF_SCN         INDX
------------ -------------------- -------------------- ------------------- ------------------- ---------- ---------------- ------------ ------------ ------------ ------------
           0 0xffffffff.ffffffff. 0x31c.14f4.0         2017-04-07 16:16:42 2017-04-07 16:16:44       2.00 13277216046         940700230  13277216052            6            0
             ffff

--//执行一些事务后,出现脏块:

REDO ( Hexadecimal ):

                                                       检查点队列
  检查点队列                                           on disk rba                                        检查点队列
    脏块数量                                           时间戳              当前时间                       on disk rba scn    检查点心跳
       CPDRT low_rba16            on_disk_rba16        CPODT               SYSDATE              DIFF_DATE CPODS                   CPHBT  CURRENT_SCN     DIFF_SCN         INDX
------------ -------------------- -------------------- ------------------- ------------------- ---------- ---------------- ------------ ------------ ------------ ------------
           4 0x31c.14f5.0         0x31c.150c.0         2017-04-07 16:16:45 2017-04-07 16:16:47       2.00 13277216057         940700233  13277216060            3            0


--//注意看low_rba16 ,on_disk_rba16就明白了.

目录
相关文章
|
关系型数据库 MySQL 数据处理
FlinkCDC 增量读取 binlog 数据比较慢
FlinkCDC 增量读取 binlog 数据比较慢
535 1
|
6月前
|
存储 SQL 关系型数据库
实时计算 Flink版操作报错合集之按时间恢复时,报错:在尝试读取binlog时发现所需的binlog位置不再可用,该怎么办
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
764 0
|
6月前
|
Oracle 关系型数据库 数据库
详细解读ADG增量恢复手册
详细解读ADG增量恢复手册
26 0
|
6月前
|
资源调度 Kubernetes Java
实时计算 Flink版产品使用问题之全量快照初始化时,如果任务异常自动从ck restore后,会从上次binlog断点续传吗
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
6月前
|
关系型数据库 中间件 MySQL
实时计算 Flink版产品使用问题之如何避免任务取消之后,检查点目录直接被删除
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
7月前
|
SQL 运维 数据处理
实时计算 Flink版产品使用合集之从指定的MySQLbinlog文件读取数据并写入本地文件,但发现任务已经对指定的binlog文件做完检查点并开始处理下一个binlog文件,该怎么处理
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStreamAPI、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
7月前
|
SQL JSON Java
Flink数据问题之checkpoint数据删除失败如何解决
Apache Flink是由Apache软件基金会开发的开源流处理框架,其核心是用Java和Scala编写的分布式流数据流引擎。本合集提供有关Apache Flink相关技术、使用技巧和最佳实践的资源。
|
Oracle 关系型数据库 数据库管理
[20171115]恢复数据文件块头3补充.txt
[20171115]恢复数据文件块头3补充.txt --// 昨天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复. --//补充几点: --1.
1144 0
|
Oracle 关系型数据库 数据库
[20171115]恢复数据文件块头4补充.txt
[20171115]恢复数据文件块头4补充.txt --// 昨天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复. --//补充几点: --1.
1067 0