- 浏览: 982738 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
孤星119:
好熟悉的数据库字段啊, 上家公司做的项目每天都跟这些字段打招呼 ...
Oracle exp compress参数引起的空间浪费 -
itspace:
quxiaoyong 写道遇到个问题,网上一搜,全他妈这篇文章 ...
数据库连接错误ORA-28547 -
quxiaoyong:
遇到个问题,网上一搜,全他妈这篇文章。你转来转去的有意思吗?
数据库连接错误ORA-28547 -
hctech:
关于version count过高的问题,不知博主是否看过ey ...
某客户数据库性能诊断报告 -
itspace:
invalid 写道写的不错,我根据这个来安装,有点理解错误了 ...
AIX 配置vncserver
首先看一下这张表格smon_scn_time在9i和10g的结构变化
9i:
10g:
一般情况下,Oracle 9i和Oracle 10g对此表更新频率维持在5分钟左右,但Oracle 10g增加了TIM_SCN_MAP字段,通过这个字段可以scn和time的转换精确到6秒钟,而9i只能精确到5分钟左右。下面分别以9i做测试:
1、
可以看到通过2种闪回机制,用scn闪回可以看到精确的数据,用TIMESTAMP 只能模糊匹配。
在研究一下TIMESTAMP 匹配了哪个scn
scn的算法是
SCN_WRP*4294967296+SCN_BAS=9744664906096
可以看到
和timestamp保持一致了。
1、10g增加了函数scn_to_timestamp,可以看到精确度相差6秒
开启10046跟踪事件跟踪一下,发现没有用到smon_scn_time
delete smon_scn_time表格内容
再次查找
可以看到还是有结果,因为可能将结果保存在pga中,开启另外一个会话就查不到了
从另外一个角度证明了函数scn_to_timestamp是从smon_scn_time取到值的
从客户的一份statspack可以看出Oracle对smon_scn_time表格的操作
9i:
引用
SQL> desc smon_scn_time
Name Null? Type
----------------------------------------- -------- ----------------------------
THREAD NUMBER
TIME_MP NUMBER
TIME_DP DATE
SCN_WRP NUMBER
SCN_BAS NUMBER
Name Null? Type
----------------------------------------- -------- ----------------------------
THREAD NUMBER
TIME_MP NUMBER
TIME_DP DATE
SCN_WRP NUMBER
SCN_BAS NUMBER
10g:
引用
SQL> desc smon_scn_time
Name Null? Type
----------------------------------------- -------- ----------------------------
THREAD NUMBER
TIME_MP NUMBER
TIME_DP DATE
SCN_WRP NUMBER
SCN_BAS NUMBER
NUM_MAPPINGS NUMBER
TIM_SCN_MAP RAW(1200)
SCN NUMBER
ORIG_THREAD NUMBER
Name Null? Type
----------------------------------------- -------- ----------------------------
THREAD NUMBER
TIME_MP NUMBER
TIME_DP DATE
SCN_WRP NUMBER
SCN_BAS NUMBER
NUM_MAPPINGS NUMBER
TIM_SCN_MAP RAW(1200)
SCN NUMBER
ORIG_THREAD NUMBER
一般情况下,Oracle 9i和Oracle 10g对此表更新频率维持在5分钟左右,但Oracle 10g增加了TIM_SCN_MAP字段,通过这个字段可以scn和time的转换精确到6秒钟,而9i只能精确到5分钟左右。下面分别以9i做测试:
1、
引用
13:38:19 SQL> SELECT LOCALTIMESTAMP FROM dual;
LOCALTIMESTAMP
---------------------------------------------------------------------------
09-JUL-09 01.38.20.890171 PM
Elapsed: 00:00:00.00
13:38:20 SQL> select dbms_flashback.get_system_change_Number scn from dual;
SCN
-------------------
9744666467101
Elapsed: 00:00:00.00
13:38:20 SQL> insert into t select * from t where rownum<10;
9 rows created.
Elapsed: 00:00:00.00
13:38:20 SQL> commit;
Commit complete.
Elapsed: 00:00:00.00
13:38:20 SQL> SELECT count(*) FROM t AS OF TIMESTAMP TO_TIMESTAMP('09-JUL-09 01.38.20.890171 PM');
COUNT(*)
----------
259047
Elapsed: 00:00:00.42
13:38:36 SQL> SELECT count(*) FROM t AS OF scn 9744666467101;
COUNT(*)
----------
260181
Elapsed: 00:00:00.35
LOCALTIMESTAMP
---------------------------------------------------------------------------
09-JUL-09 01.38.20.890171 PM
Elapsed: 00:00:00.00
13:38:20 SQL> select dbms_flashback.get_system_change_Number scn from dual;
SCN
-------------------
9744666467101
Elapsed: 00:00:00.00
13:38:20 SQL> insert into t select * from t where rownum<10;
9 rows created.
Elapsed: 00:00:00.00
13:38:20 SQL> commit;
Commit complete.
Elapsed: 00:00:00.00
13:38:20 SQL> SELECT count(*) FROM t AS OF TIMESTAMP TO_TIMESTAMP('09-JUL-09 01.38.20.890171 PM');
COUNT(*)
----------
259047
Elapsed: 00:00:00.42
13:38:36 SQL> SELECT count(*) FROM t AS OF scn 9744666467101;
COUNT(*)
----------
260181
Elapsed: 00:00:00.35
可以看到通过2种闪回机制,用scn闪回可以看到精确的数据,用TIMESTAMP 只能模糊匹配。
在研究一下TIMESTAMP 匹配了哪个scn
引用
13:43:14 SQL> SELECT TIME_DP, SCN_WRP, SCN_BAS from SMON_SCN_TIME where TIME_DP < = to_date('2009-07-09 13:38:19','yyyy-mm-dd hh24:mi:ss' ) ORDER BY TIME_DP desc ;
TIME_DP SCN_WRP SCN_BAS
------------------- ---------- ----------
2009-07-09 13:33:20 2268 3680638917
TIME_DP SCN_WRP SCN_BAS
------------------- ---------- ----------
2009-07-09 13:33:20 2268 3680638917
scn的算法是
SCN_WRP*4294967296+SCN_BAS=9744664906096
可以看到
引用
13:44:06 SQL> SELECT count(*) FROM t AS OF scn 9744666466245;
COUNT(*)
----------
259047
COUNT(*)
----------
259047
和timestamp保持一致了。
1、10g增加了函数scn_to_timestamp,可以看到精确度相差6秒
引用
SQL> select scn_to_timestamp(9744666543478) from dual;
SCN_TO_TIMESTAMP(9744666543478)
---------------------------------------------------------------------------
09-JUL-09 03.33.47.000000000 PM
SQL> select scn_to_timestamp(9744666543477) from dual;
SCN_TO_TIMESTAMP(9744666543477)
---------------------------------------------------------------------------
09-JUL-09 03.33.41.000000000 PM
SCN_TO_TIMESTAMP(9744666543478)
---------------------------------------------------------------------------
09-JUL-09 03.33.47.000000000 PM
SQL> select scn_to_timestamp(9744666543477) from dual;
SCN_TO_TIMESTAMP(9744666543477)
---------------------------------------------------------------------------
09-JUL-09 03.33.41.000000000 PM
开启10046跟踪事件跟踪一下,发现没有用到smon_scn_time
引用
*** 2009-07-09 15:45:34.627
*** SERVICE NAME:(SYS$USERS) 2009-07-09 15:45:34.627
*** SESSION ID:(132.250) 2009-07-09 15:45:34.627
WAIT #3: nam='SQL*Net message to client' ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896029909494
WAIT #3: nam='SQL*Net message from client' ela= 3616167 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896033525929
=====================
PARSING IN CURSOR #1 len=48 dep=0 uid=0 oct=3 lid=0 tim=1217896033527758 hv=2148814857 ad='3912114c'
select scn_to_timestamp(9744666543477) from dual
END OF STMT
PARSE #1:c=2000,e=1728,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1217896033527753
BINDS #1:
EXEC #1:c=0,e=48,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1217896033527918
WAIT #1: nam='SQL*Net message to client' ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896033527950
FETCH #1:c=0,e=77,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=1217896033528057
WAIT #1: nam='SQL*Net message from client' ela= 126 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896033528238
FETCH #1:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1217896033528268
WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896033528293
*** SERVICE NAME:(SYS$USERS) 2009-07-09 15:45:34.627
*** SESSION ID:(132.250) 2009-07-09 15:45:34.627
WAIT #3: nam='SQL*Net message to client' ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896029909494
WAIT #3: nam='SQL*Net message from client' ela= 3616167 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896033525929
=====================
PARSING IN CURSOR #1 len=48 dep=0 uid=0 oct=3 lid=0 tim=1217896033527758 hv=2148814857 ad='3912114c'
select scn_to_timestamp(9744666543477) from dual
END OF STMT
PARSE #1:c=2000,e=1728,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1217896033527753
BINDS #1:
EXEC #1:c=0,e=48,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1217896033527918
WAIT #1: nam='SQL*Net message to client' ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896033527950
FETCH #1:c=0,e=77,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=1217896033528057
WAIT #1: nam='SQL*Net message from client' ela= 126 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896033528238
FETCH #1:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1217896033528268
WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1217896033528293
delete smon_scn_time表格内容
引用
SQL> alter system set events '12500 trace name context forever, level 10';
System altered.
SQL> delete from smon_scn_time;
1808 rows deleted.
SQL> commit;
Commit complete.
SQL> alter system set events '12500 trace name context off';
System altered.
System altered.
SQL> delete from smon_scn_time;
1808 rows deleted.
SQL> commit;
Commit complete.
SQL> alter system set events '12500 trace name context off';
System altered.
再次查找
引用
SQL> select scn_to_timestamp(9744666543478) from dual;
SCN_TO_TIMESTAMP(9744666543478)
---------------------------------------------------------------------------
09-JUL-09 03.33.47.000000000 PM
SCN_TO_TIMESTAMP(9744666543478)
---------------------------------------------------------------------------
09-JUL-09 03.33.47.000000000 PM
可以看到还是有结果,因为可能将结果保存在pga中,开启另外一个会话就查不到了
引用
SQL> select scn_to_timestamp(9744666543478) from dual;
select scn_to_timestamp(9744666543478) from dual
*
ERROR at line 1:
ORA-08181: specified number is not a valid system change number
ORA-06512: at "SYS.SCN_TO_TIMESTAMP", line 1
select scn_to_timestamp(9744666543478) from dual
*
ERROR at line 1:
ORA-08181: specified number is not a valid system change number
ORA-06512: at "SYS.SCN_TO_TIMESTAMP", line 1
从另外一个角度证明了函数scn_to_timestamp是从smon_scn_time取到值的
从客户的一份statspack可以看出Oracle对smon_scn_time表格的操作
引用
Buffer Gets Executions Gets per Exec %Total CPU-Time(s) Elapsd-Time (s) Hash Value
--------------- ------------ ---------- ----- ------ --------- -----------
delete from smon_scn_time where thread=0 and scn = (select min(
scn) from smon_scn_time where thread=0)
--------------- ------------ ---------- ----- ------ --------- -----------
delete from smon_scn_time where thread=0 and scn = (select min(
scn) from smon_scn_time where thread=0)
发表评论
-
buffer cache 的内部结构
2020-03-18 14:21 585BUFFER CACHE作为数据块的 ... -
Oracle OMC介绍
2020-03-18 13:19 496Oracle管理云服务(OMC)的大数据平台,自动收集的企业 ... -
参加Oracle勒索病毒防范专题培训会议
2019-09-27 17:15 5342019年7月22日,受邀参加Oracle勒索病毒防范专题培训 ... -
记一次内存换IO的Oracle优化
2019-09-27 16:50 836某客户数据库从P595物理 ... -
如何定位Oracle SQL执行计划变化的原因
2019-07-03 14:49 1474性能优化最难的是能够 ... -
如何定位Oracle SQL执行计划变化的原因
2018-10-30 09:24 1185性能优化最难的是能够 ... -
数据库性能优化目标
2018-10-08 10:59 529从数据库性能优化的场 ... -
数据库无法打开的原因及解决办法
2018-10-05 20:45 2148数据库的启动是一个相当复杂的过程。比如,Oracle在启动之前 ... -
怎么样彻底删除数据库?
2018-09-18 11:10 609Oracle提供了drop database命令用来删除数据库 ... -
Oracle减少日志量的方法
2018-09-10 10:17 872LGWR进程将LOG BUFFER中的 ... -
如何快速关闭数据库
2018-09-09 13:14 1242“一朝被蛇咬,十年怕井绳”。在没被“蛇”咬之前,很多DBA喜欢 ... -
关于《如何落地智能化运维》PPT
2018-05-17 10:19 1140在DTCC 2018发表《如何落地智能化运维》演讲,主要内容如 ... -
记录在redhat5.8平台安装oracle11.2容易忽视的几个问题
2018-05-11 19:58 588问题一:ping不通问题 在虚拟机上安装好linux系统后, ... -
《Oracle DBA实战攻略》第一章
2018-05-11 10:42 966即日起,不定期更新《OracleDBA实战攻略》一书电子版,请 ... -
Oracle 12c新特性
2018-05-11 10:33 908查询所有pdb [oracle@gj4 ~]$ sqlplu ... -
关于修改memory_target的值后数据库无法启动的问题
2017-02-28 12:24 3991操作系统:RHEL6.5 数据库版本:11.2.0.4 ... -
10g rac安装error while loading shared libraries libpthread.so.0 问题
2017-02-28 12:22 70511g rac安装在二节点跑脚本一般会报此错误: 解决这个问 ... -
记一次Oracle会话共享模式故障处理过程
2017-02-27 19:16 808故障简述 XXX第八人民医院HIS数据库7月13日11点左右从 ... -
RESMGR:cpu quantum等待事件处理过程
2017-02-27 18:23 2672由于数据库上线过程中出现大量的RESMGR:cpu quant ... -
谈谈log file sync
2014-03-19 14:18 1781数据库中的log file sync等待事件指的是,当user ...
相关推荐
create unique index smon_scn_time_tim_idx on smon_scn_time(time_mp); ``` - **重启数据库**:最后,使用`shutdown immediate`命令关闭数据库,并使用`startup force`命令重启数据库以确保所有的更改生效。 #...
SMON进程会定期更新SMON_SCN_TIME表,使得SCN和时间戳能够相互转换。 在不完全恢复的场景中,SCN的使用也非常重要。不完全恢复通常发生在需要将数据库回滚到某一个时间点,但是不是完全恢复到上一次完全备份的时间...
SQL> CREATE INDEX "SYS"."SMON_SCN_TO_TIME_AUX_IDX" ON CLUSTER "SYS"."SMON_SCN_TO_TI PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS...
SELECT SCN, TO_CHAR(TIME_DP, 'YYYY-MM-DD HH24:MI:SS') FROM SYS.SMON_SCN_TIME; ``` #### 六、实际操作演示 以下是一个基于10g版本Oracle的闪回示例: 1. **登录数据库**: ```sql SQL> sqlplus tivan/tivan...
SMON还做了许多其他事情,例如,在DBA_TAB_MONITORING视图中的监控统计数据的洗刷,在SMON_SCN_TIME表中的时间戳定位信息的洗刷,等等。SMON在期间能消耗很多CPU,这应该被认为是正常的。SMON周期性的苏醒(或被其他...
锁定SMON的并行恢复(FAST_START_PARALLEL_ROLLBACK)无效,因为表SYS.smon_scn_time被锁住。此表用于记录SCN(System Change Number)到系统时间的映射,与UNDO表空间增长的时间一致。使用systemstate dump工具观察...
然而,使用`SCN_TO_TIMESTAMP`可能会遇到`ORA-08181`错误,因为SCN与时间戳的转换依赖于`SMON_SCN_TIME`基表中的采样记录。由于SMON进程会定期清理旧的SCN记录,对于较早的SCN,转换可能会失败。 第二种方法是利用`...
3. **SCN的记录**:每当事务提交时,都会被分配一个SCN(System Change Number),这有助于保证在分布式环境下的数据一致性。 #### SMON:系统监控进程 **功能介绍**: SMON(System Monitor Process)是负责在...