银符考试题库B12
现在是:
试卷总分:100.0
您的得分:
考试时间为:
点击“开始答卷”进行答题
项目 | sourcedb | |||||||||||||||||||||||
db类型 | RAC | |||||||||||||||||||||||
db version | 10.2.0.5.0 | |||||||||||||||||||||||
db存储 | ASM | |||||||||||||||||||||||
OS版本及kernel版本 | AIX 64位 6.1.0.0 |
模式代码 | 解释 | |||||||||||||||||||
1 | Null Mode | |||||||||||||||||||
2 | Sub-Shoe | |||||||||||||||||||
3 | Sub-Exclusive | |||||||||||||||||||
4 | Share | |||||||||||||||||||
5 | Share/Sub-Exclusive | |||||||||||||||||||
6 | Exclusive |
锁 | row cache lock | SQ锁(Sequence Cache) | SV锁(Sequence Ordering) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
产生的条件 | NOCACHE | CACHE+NOORDER或CACHE+ORDER (单实例) |
CACHE+ORDER(RAC) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
拥有的锁模式 | 6-X(Exclusive) | 6-X(Exclusive) | 5-SSX(Share/Sub-Exclusive) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
表现出的等 待事件 |
row cache lock | enq:SQ-contention | Oracle 10g表现为DFS lock handle,而 Oracle 11g中表现为enq:SV-contention |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
简介 | 在赋予了NOCACHE属性 的序列上,在调用 SEQUNECE.NEXTVAL过 程中,将数据字典信息进行 物理修改时拥有该锁,等待 事件表现为row cache lock |
赋予了CACHE属性的序列调刖 NEXTVAL期间,应该以SSX模式获得SQ 锁。若许多会话同时为了获取SQ锁而发生 争用,则等待enq:SQ-contention事件 |
在RAC上节点之间顺序得到保障的情况 下,调用SEQUENCE.NEXTVAL期间拥有 该锁。在RAC环境中,赋予CACHE+ORDER 属性的序列上发生,在Oracle 10g表现为 DFS lock handle,而在Oracle 11g中表现为 enq:SV-contention。解决办法:尽量设置为 NOORDER并增大其CACHE值 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
参数含义 | P1代表V$ROWCACHE 中的CACHE# |
P1可以查询到锁的名称和请求的MODE 值。P2值是序列的OBJECT_ID。因此,若 利用P2值与DBA_OBJECTS的结合,就可 以知道对哪个序列发生了等待现象 |
P1可以查询到锁的名称和请求的MODE值 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
解决办法 | 尽量设置为NOORDER属性并增大其CACHE值,一般情况下可以增大到1000 |
恢复模型 | 优点 | 工作损失表现 | 能否恢复到即时点? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
简单恢复 | 1)允许高性能大容量复制操作 2)收回日志空间以使空间要求最小 |
必须重做自最新的数据库或差异备份后所发生 的更改 |
可以恢复到任何备份的结 尾处,随后必须重做更改 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
完全恢复 | 1)数据文件丢失或损坏不会导致工作损失 2)可以恢复到任意即时点(例如,应用 程序或用户错误之前) |
1)正常情况下没有 2)如果日志损坏,那么必须重做自最新的目志 备份后所发生的更改 |
可以恢复到任何即时点 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
大容量日志 记录恢复 |
允许高性能大容量复制操作。大容量操作 使用最少的日志空间 |
如果日志损坏,或者自最新的日志备份后发生了 大容量操作,那么必须重做自上次备份后所做的更 改,否则不丢失任何工作 |
可以恢复到任何备份的结 尾处,随后必须重做更改 |
名称 | 悲观锁(Pessimistic Lcck) | 乐观锁(Optimistic Lock) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
描述 | 顾名思义,很悲观。每次去读数据 的时候,都认为别的事务会修改数据, 所以,每次在读数据的时候都会上锁, 防止其他事务读取或修改这些数据, 这样导致其他事务会被阻塞,直到这 个事务结束 |
顾名思义,很乐观。每次去拿数据的时候都认为别人不会修改,所以,不会上 锁,但是在更新的时候会判断在此期间别人有没有去更新这个数据。乐观锁一般 通过增加时间戳字段来实现,认为数据不会被其他用户修改,所以,只需要修改 屏幕上的信息而不需要锁 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
应用场 | 数据更新比较频繁的场合 | 数据更新不频繁、查询比较多的场合,这样可以提高吞吐量 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
更新丢 失解决 方案 |
试图在更新之前把行锁住,使用 SELECT...FORUPDATE,然后更新数 据 |
1)使用版本列的乐观锁定增加NUMBER、TIMESTAMP或DATE列,通过增 加一个时间戳列,可以知道最后修改时间。每次修改行时,检查数据库中这一列 的值与最初读出的值是否匹配。若匹配则修改数据且通过触发器来负责递增 NUMBER、DATE、TIMESTAMP 2)使用校验和的乐观锁定用基数据本身来计算一个“虚拟的”版本列,生成散 列值进行比较。数据库独立性好,从CPU使用和网络传输方面来看,资源开销量大 3)使用ORA_ROWSCN的乐观锁定建立在Oracle SCN的基础上,在建表时, 需要启用ROWDEPENDENCIES,防止整个数据块的ORA_ROWSCN向前推进。 可以用SCN_TO TIMESTAMP (ORA_ROWSCN)将SCN转换为时间格式。将原先 的悲观锁机制修改为乐观锁来控制并发,可以使用ORA_ROWSCN,这样可以无 须增加新列。也可以通过SCN_TO_TIMESTAMP来获取最后修改时间 |