Author: mac

GGSCI中显示的LAG代表 事务被写入到磁盘介质中的时刻例如Oracle中redo被写入到online redo logfile中 和 Replicat将同一个事务分发到目标数据库的时刻 之间的时间间隔。   通俗地说，一个事务内的所有行记录将对应同一个LAG； 除非出现了一个事务被打散且被多个REPLICAT分别apply或者变成多个事务的情况。 OGG参数例如RANGE这种对应于第一种情况，即一个事务被多个REPLICATE分别APPLY。 OGG参数MAXTRANSOPS对应后一种情况。   LAG在以下情况中被引入：   当Extract进程在读取redolog并写出到TRAIL或REMOTE HOST 当额外的datapump在读取extract trail并通过网络写出到远程节点REMOTE HOST 当collector在目标服务器上接受网络数据并写出到LOCAL TRAIL 当REPLICAT读取LOCAL TRAIL并写出到数据库中     同时也需要注意通过GGSCI中INFO或STATUS等命令显示的LAG，或通过SEND 对象名,LAG命令获得的LAG可能不一致：   INFO命令所获得的LAG可能与SEND命令所得值存在小的差别 INFO命令获得的LAG返回自MANAGER来源于最近记录的checkpoint SEND <OBJECT>, lag获得的LAG值基于<OBJECT>正在处理的行记录的时间戳 LAG常使用时间单位或需要处理的数据单位Kilobytes来表达   归根结底LAG是衡量 数据归档或写出到日志的时间 和 EXTRACT/PUMP/REPLICAT处理该数据的时刻 这2个时间点之间的差距， 而不是说 LAG反映了EXTRACT还要工作多久。   实际EXTRACT/PUMP/REPLICAT都不知道自己要工作多久才能追上 REAL TIME，它们的LAG值只是显示 最近它们处理的一条记录的时间 和这条记录被写到REDO LOG的时间点之间的差距，即LAG只说明ER之前的工作延迟，不代表还要工作多久才能追平。   举个例子来说，STOP EXTRACT之后等待一段时间再重启看到有很大的LAG，这不代表EXTRACT有什么问题，只是EXTRACT最后处理的一条记录 很早就在REDO LOG里生成了…

HANDLECOLLISIONS是我们使用goldengate过程中常有的一个REPLICAT参数，该参数依赖于主键或唯一索引处理冲突数据，常用于初始化阶段。对于无主键或唯一索引的表无法处理冲突，且可能导致重复记录。注意打开此参数则所有数据错误不管reperror如何配置均不再写discard文件，即所有数据冲突信息被默认规则处理，没有任何日志(则会忽略error mapping数据错误，而且不会报告到discard文件)，因此日常复制不建议使用该参数；可予以考虑的特殊场景为只需新增数据，无需复制历史数据。   使用HANDLECOLLISIONS的几个场景： target丢失delete记录(missing delete)，忽略该问题并不记录到discardfile target丢失update记录(missing update) 更新的键值是主键=》 update转换成INSERT ，默认情况下插入记录不完整 更新的键值是非主键=》 忽略该问题并不记录到discardfile 重复插入已存在的主键值到target表中，这将被replicat转换为UPDATE现有主键值的行的其他非主键列 情景1 target丢失delete记录(missing delete) ： C:\Users\ML>sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Tue Sep 18 13:38:03 2012 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production With the Partitioning,…

Oracle Premier、Extended、Sustaining Support的区别可以参考下表:   Key Features Premier Support Extended Support Sustaining Support Major Product and Technology Releases Technical Support Access to Knowledge Base Updates and Fixes Pre-existing Security Alerts Pre-existing Critical Patch Updates Pre-existing Tax, Legal, and Regulatory Updates Pre-existing Upgrade Tools/Scripts Pre-existing Certification with most existing Oracle products Certification with most existing third-party products/versions…

补丁11.2.0.3中修复的bug列表     11.2.0.3 Bug Fixes by Category   Advanced Networking Option Advanced Networking Option 9215461 TDE wallet master rekey fails with ORA-28362 or creation of encrypted tablespace fails with ORA-28374 Undocumented Advanced Networking Option 8866524 9056628 9249366 10395645   JDBC JDBC 3742224 ORA-1017 reported instead of ORA-1031 when trying to connect via JDBC thin…

网友在OTN中文官方技术论坛上提问问题： “Exadata在rman备份时候的offloading功能需要数据库打开BCT吗？同题目，BCT=Block Change Tracking。 oracle数据库中BCT是使用文件来记录一组数据块中，修改过的数据块做个标记。 rman备份时，exadata的 offloading是如何实现的呢？”   As Maclean answered “exadata的 offload incremental backup optimization 是基于数据块为单位， 而block change tracking通过位图维护一组block， 所以 offload incremental backup的 粒度更细化 也更智能。 With Exadata，changes are tracked at the individual oracle block level rather than at the level of a large group of blocks. This result in less I/O bandwidth being consumed…

在启动数据库 (指database open)时若需要recovery的redo较多，涉及到的数据块多时可能会看到以下信息: > Buffer cache spillover: only 32768 of 117227 buffers available$   这是由于crash recovery的redo apply本身需要用到buffer cache，此时buffer cache被称作recovery buffer。 一旦分配了recovery buffer，其将不会被释放或age out直到所有数据块的redo change都被应用并写入到磁盘。   由于只有一个实例可以参与recovery(不管是crash recovery还是instance recovery)，恢复实例的buffer cache 大小将会是大规模恢复数据文件(recovery)的限制。 在锁声明阶段(lock claim phase)，若实例耗尽了空余的buffer cache 则会spillover溢出到磁盘上(有点像swap)并必须予以处理。此时锁声明会暂时中止，oracle会先应用日志将redo change应用到哪些已经声明过的buffer cache中。直到所有这些recovery buffer都被恢复并被写出，此时它们才变得对下一次后续的锁声明可用。 由于以上说明的磁盘溢出恢复(spillover recovery)持续多次锁声明和日志应用阶段(理想的是一次锁声明，一次日志应用即完成redo apply)，直到本次完整的恢复完成。 需要注意的是，以上crash recovery的算法在 buffer cache很小的情况下性能较差； 常见的例子是这样的， 在产品数据库中由于有着较大buffer cache而不会遇到该问题，而在某些基于存储或卷管理软件实现的复制、测试环境中，由于需要恢复的数据集合较大而且往往db_cache_size比产品库小很多，所以alter database open时往往看到该(Buffer cache spillover: only 32768 of…

kkeCostToTime: using io calibrate stats maxpmbps=36(MB/s) block_size=8192 mb_io_count=1 mb_io_size=8192 (bytes) tot_io_size=4(MB) time=113(ms) kkeCostToTime: using io calibrate stats maxpmbps=36(MB/s) block_size=8192 mb_io_count=1 mb_io_size=8192 (bytes) tot_io_size=4(MB) time=113(ms) Starting SQL statement dump   can affect DOP .       “So starting with 11.2.0.2 the new “cost is time” calculation comes into the picture. If you have values in…

Know more _high_priority_processes   LMS process priority? In release 9i, increasing LMS process priority to RT or FX (with larger CPU quanta scheduling schemes) helps. Oracle Corporation has already identified this potential issue and in release 10g, this issue is taken care of, and LMS processes are running with RT priority. This alleviates many issues…

了解你所不知道的SMON功能系列文章汇总:   了解你所不知道的SMON功能(一):清理临时段 了解你所不知道的SMON功能(二):合并空闲区间 了解你所不知道的SMON功能(三):清理obj$基表 了解你所不知道的SMON功能(四):维护col_usage$字典基表 了解你所不知道的SMON功能(五):Recover Dead transaction 了解你所不知道的SMON功能(六):Instance Recovery 了解你所不知道的SMON功能(七):清理IND$字典基表 了解你所不知道的SMON功能(八):Transaction Recover 了解你所不知道的SMON功能(九):维护MON_MODS$字典基表 了解你所不知道的SMON功能(十):维护SMON_SCN_TIME字典基表 了解你所不知道的SMON功能(十一):OFFLINE UNDO SEGMENT 了解你所不知道的SMON功能(十二):Shrink UNDO(rollback) SEGMENT     SMON的功能并不止于此，详细完整的功能列表： 实施local instance recovery 实施OPS/RAC instance recovery 服务于排序段sort segment申请 实施transaction recovery(rollback) 清理不再使用的临时段temporary segments 清理已经被aged out的游标所使用的临时表temporary tables 清理dead instance的临时表temporary tables  删除OBJ$基表上不再存在的对象记录  若index online rebuild失败，则负责清理ind$和indpart$ 合并extents 在适当的时机收缩 rollback segment 在适当的实际offline rollback segment 恢复crash/instance…

在写了几封邮件之后OTN中文论坛 (https://forums.oracle.com/forums/forum.jspa?forumID=314&start=0)上的垃圾广告贴基本都被删干净了，还这个官方中文论坛一个清净优雅！ 今后将持续参与OTN中文论坛的讨论，希望发展到T.askmac.cn之前的繁荣度！