课程第23/24次（2017-04-16星期日下午晚上）

botang

上完1Z0-052的第5章
进行1Z0-053的第10章
1Z0-051共12章（上完10章），1Z0-052共19章（上完10章），1Z0-053共21章（上完2章）
总共上完全部52章中的22章

1. select   name , group_number  ,
   
2.            total_mb,
   
3.         usable_file_mb from v$asm_diskgroup;
   
4. 
   
5. select  * from v$asm_attribute  where group_number=3;
   
6. 
   
7. select  * from v$asm_operation;
   
8. 
   
9. select    *
   
10.       from v$asm_disk
    
11.         where group_number=1;
    
12.       
    
13.    alter diskgroup data add failgroup data_0000
    
14.      disk '/dev/raw/raw16' size  990M
    
15.      drop   disk data_0005
    
16.      rebalance power 11;
    
17.      
    
18.      select  group_number, name, path, failgroup  from v$asm_disk
    
19.        where group_number=1
    
20.        order by failgroup;
    
21.       
    
22.        -----
    
23.       
    
24.        SQL> alter diskgroup data add failgroup data_0001
    
25.   2   disk '/dev/raw/raw10'
    
26.   3    failgroup data_0001
    
27.   4    disk '/dev/raw/raw12';
    
28. alter diskgroup data add failgroup data_0001
    
29. *
    
30. ERROR at line 1:
    
31. ORA-15032: not all alterations performed
    
32. ORA-15029: disk '/dev/raw/raw10' is already mounted by this instance
    
33. 
    
34. 
    
35. SQL> alter diskgroup drop disk data_0003;
    
36. alter diskgroup drop disk data_0003
    
37.                 *
    
38. ERROR at line 1:
    
39. ORA-15100: invalid or missing diskgroup name
    
40. 
    
41. 
    
42. SQL>  alter diskgroup  data drop disk data_0003;
    
43. alter diskgroup  data drop disk data_0003
    
44. *
    
45. ERROR at line 1:
    
46. ORA-15032: not all alterations performed
    
47. ORA-15071: ASM disk "DATA_0003" is already being dropped
    
48. 
    
49. 
    
50. SQL> alter diskgroup  data drop disk data_0003 force ;
    
51. 
    
52. Diskgroup altered.
    
53. 
    
54. SQL> alter diskgroup data add failgroup data_0001 disk '/dev/raw/raw10' name data_0003 ;
    
55. alter diskgroup data add failgroup data_0001 disk '/dev/raw/raw10' name data_0003
    
56. *
    
57. ERROR at line 1:
    
58. ORA-15032: not all alterations performed
    
59. ORA-15033: disk '/dev/raw/raw10' belongs to diskgroup "DATA"
    
60. 
    
61. 
    
62. SQL> alter diskgroup data add failgroup data_0001 disk '/dev/raw/raw10' name data_0003  force ;
    
63. 
    
64. Diskgroup altered.
    
65. 
    
66. SQL>  alter diskgroup data add failgroup data_0001 disk '/dev/raw/raw12' name data_0007
    
67.   2                        drop disk data_0004;
    
68. 
    
69. Diskgroup altered.
    
70. 
    
71. SQL> alter diskgroup data add failgroup data_0000  disk '/dev/raw/raw11' name data_0004;
    
72. 
    
73. Diskgroup altered.
    
74. 
    
75. SQL> alter diskgroup newdata set attribute 'compitable.asm'='11.1';
    
76. alter diskgroup newdata set attribute 'compitable.asm'='11.1'
    
77. *
    
78. ERROR at line 1:
    
79. ORA-15032: not all alterations performed
    
80. ORA-15242: could not set attribute compitable.asm
    
81. ORA-15221: ASM operation requires compatible.asm of 11.1.0.0.0 or higher
    
82. 
    
83. 
    
84. SQL> alter diskgroup newdata set attribute 'compitable.asm'='11.2';
    
85. alter diskgroup newdata set attribute 'compitable.asm'='11.2'
    
86. *
    
87. ERROR at line 1:
    
88. ORA-15032: not all alterations performed
    
89. ORA-15242: could not set attribute compitable.asm
    
90. ORA-15221: ASM operation requires compatible.asm of 11.1.0.0.0 or higher
    
91. 
    
92. 
    
93. SQL> alter diskgroup newdata set attribute 'compatible.asm'='11.1';
    
94. 
    
95. Diskgroup altered.
    
96. 
    
97. SQL> alter diskgroup newdata set attribute 'compatible.asm'='10.1';
    
98. alter diskgroup newdata set attribute 'compatible.asm'='10.1'
    
99. *
    
100. ERROR at line 1:
     
101. ORA-15032: not all alterations performed
     
102. ORA-15242: could not set attribute compatible.asm
     
103. ORA-15244: new compatibility setting less than current [11.1.0.0.0]
     
104. 
     
105. 
     
106. SQL> alter diskgroup newdata set attribute 'compatible.asm'='11.2';
     
107. 
     
108. Diskgroup altered.
     
109. 
     
110. SQL>  alter diskgroup newdata   offline disk fgroup4d1  drop after 3.6h;
     
111. alter diskgroup newdata   offline disk fgroup4d1  drop after 3.6h
     
112. *
     
113. ERROR at line 1:
     
114. ORA-15032: not all alterations performed
     
115. ORA-15283: ASM operation requires compatible.rdbms of 11.1.0.0.0 or higher
     
116. 
     
117. 
     
118. SQL>  alter diskgroup newdata   offline disk fgroup4d1  drop after 30m;
     
119. alter diskgroup newdata   offline disk fgroup4d1  drop after 30m
     
120. *
     
121. ERROR at line 1:
     
122. ORA-15032: not all alterations performed
     
123. ORA-15283: ASM operation requires compatible.rdbms of 11.1.0.0.0 or higher
     
124. 
     
125. 
     
126. SQL>  alter diskgroup newdata   offline disk fgroup4d1  drop after 10m;
     
127. alter diskgroup newdata   offline disk fgroup4d1  drop after 10m
     
128. *
     
129. ERROR at line 1:
     
130. ORA-15032: not all alterations performed
     
131. ORA-15283: ASM operation requires compatible.rdbms of 11.1.0.0.0 or higher
     
132. 
     
133. 
     
134. SQL>  alter diskgroup newdata   offline disk fgroup4d1  drop after 0h;
     
135. alter diskgroup newdata   offline disk fgroup4d1  drop after 0h
     
136. *
     
137. ERROR at line 1:
     
138. ORA-15032: not all alterations performed
     
139. ORA-15283: ASM operation requires compatible.rdbms of 11.1.0.0.0 or higher
     
140. 
     
141. 
     
142. SQL>  alter diskgroup newdata   offline disk fgroup4d1 ;
     
143. alter diskgroup newdata   offline disk fgroup4d1
     
144. *
     
145. ERROR at line 1:
     
146. ORA-15032: not all alterations performed
     
147. ORA-15283: ASM operation requires compatible.rdbms of 11.1.0.0.0 or higher
     
148. 
     
149. 
     
150. SQL> alter diskgroup newdata set attribute 'compatible.rdbms'='11.2';
     
151. 
     
152. Diskgroup altered.
     
153. 
     
154. SQL> alter diskgroup newdata set attribute 'compatible.rdbms'='11.1';
     
155. alter diskgroup newdata set attribute 'compatible.rdbms'='11.1'
     
156. *
     
157. ERROR at line 1:
     
158. ORA-15032: not all alterations performed
     
159. ORA-15242: could not set attribute compatible.rdbms
     
160. ORA-15244: new compatibility setting less than current [11.2.0.0.0]
     
161. 
     
162. 
     
163. SQL>  alter diskgroup newdata   offline disk fgroup4d1  drop after 10m;
     
164. 
     
165. Diskgroup altered.
     
166. 
     
167. SQL> alter diskgroup newdata online disk fgroup4d1;
     
168. 
     
169. Diskgroup altered.
     
170. 
     
171. SQL>  alter diskgroup newdata   offline disk fgroup4d1  drop after 5m;
     
172. 
     
173. Diskgroup altered.
     
174. 
     
175. SQL>
     
176. 
     
177.       
     
178.       
     

复制代码

若是管理员决定撤销某个或某些事务，Oracle提供一个专门用来撤销事务的工具——闪回事务。

闪回事务又名撤销事务（Transaction Backout），能够撤销一个或多个事务的修改，其功能由一个名为DBMS_FLASHBACK.TRANSACTION_BACKOUT的存储过程实现。该存储过程的工作原理是自动分析重做日志，挖掘出变更前的值用以构建撤销SQL（Undo SQL），然后执行撤销SQL最后达到撤销事务的目的。




为了该功能可以正常使用，至少需要事先启用主键补充日志。另外，为了能够跟踪外键依赖还需要启用外键补充日志。






在继续讨论此功能前，首先应了解一个概念：事务的依赖性。比如，两个事务TX1和TX2，若符合以下3个条件的任意一个就可以认为TX2依赖TX1：

（1）WAW依赖（Write After Write），即在TX1修改了表的某行之后，TX2又修改了同一行。


（2）主键依赖，即在一张拥有主键的表中TX1首先删除了一行，之后TX2又插入了具有相同主键值的另一行。

（3）外建依赖，即由于TX1的修改（insert或update）而产生了新的可被外键参考的字段值，之后TX2修改（insert或update）外键字段时利用了TX1所产生的字段值。





了解事务依赖性有助于解决在撤销事务时遇到的矛盾，以主键依赖为例，试想若直接将事务TX1撤销并且不理会事务TX2，岂不是会出现主键值重复的行！

TRANSACTION_BACKOUT存储过程的OPTIONS参数就是为了解决事务依赖性问题而存在的，在该参数上管理员可以使用4种撤销事务的方案，假设被撤销的事务是TX1，若其具有依赖事务，则称为TX2：

（1）NOCASCADE，TX1不可以被任何其他事务依赖（即TX2不存在），否则撤销操作报错。

（2）CASCADE，将TX1连同TX2一起撤销。

（3）NOCASCADE_FORCE，忽略TX2，直接执行TX1的撤销SQL将TX1撤销，如果没有约束上的冲突，操作将成功，否则约束报错导致撤销操作失败。

（4）NONCONFILICT_ONLY，在不影响TX2的前提下，撤销TX1的修改。与NOCASCADE_FORCE的不同点在于会首先过滤一下TX1的撤销SQL，确保它们不会作用在TX2修改的行上。

接下来以WAW依赖为例详细说明，比如有一张表的原有数据如下所示，只有3行且没有约束：TX1

        ID
----------
         1
         2
         3

接下来先后发起事务TX2和TX3仅修改该表。在事务TX2（更新了3行）执行后其数据变更为：

        ID
----------
        11
        22
        33

之后，在事务TX3（更新了两行，第一行没有修改）执行后其数据变更为：

        ID
----------
        11
       222
       333



(***TX4  222->22)

此例为典型的WAW依赖，TX3依赖TX2依赖TX1。

现在计划将事务TX2撤销，那么使用不同的OPTIONS将产生不同的结果。

若采用NOCASCADE结果是抛出错误“ORA-55504: Transaction conflicts in NOCASCADE mode”，表内容依然是：

ID
------
  11
222
333



      

若采用CASCADE，表的内容恢复到TX3和TX2均未执行的状态：

        ID
----------
         1
         2
         3

若采用NOCASCADE_FORCE，TX3的结果不受影响，但被TX2修改的第一行回滚了，闪回事务没有尊重TX1的事务原子性。表的内容变为：

        ID
----------
         1  (where id=11)
       222  (where id=22)
       333  (where id=33)

也许读者会感到奇怪，根据NOCASCADE_FORCE的定义，会在所有行上执行撤销SQL，那为什么第2和第3行的内容没有回到TX2执行之前呢？原因是此例中撤销SQL的where语句中还包含ID字段的值，这是启用了主键补充日志的结果：

update <表名> set "ID" = '1' where "ID" = '11' and ROWID = <第1行ROWID>;
update <表名> set "ID" = '2' where "ID" = '22' and ROWID = <第2行ROWID>;
update <表名> set "ID" = '3' where "ID" = '33' and ROWID = <第3行ROWID>;

没记错的话第2和第3行的ID字段已经被TX3分别修改为222和333了，所以虽然执行了3条撤销SQL，但只有第1行得到了修改。



若采用NONCONFILICT_ONLY，在此例中将产生与NOCASCADE_FORCE一样的结果：

        ID
----------
         1 (where id=11)
       222
       333

读者需要明白本情况中的撤销SQL应该只有一条：

update <表名> set "ID" = '1' where "ID" = '11' and ROWID = <第1行ROWID>;

虽然最后的结果是相同的，但是与NOCASCADE_FORCE所做的尝试是不同的，和TX3有关的对第2行、第3行的更改命令首先被过滤了。试想若在事务TX3之后还有一个事务TX4又将第行的ID字段改回22，再使用NOCASCADE_FORCE和NONCONFILICT_ ONLY将TX2闪回，结果将会怎样。

使用DBMS_FLASHBACK.TRANSACTION_BACKOUT的步骤如下：

（1）将需要撤销的事务的事务号或事务名载入对应的VARRAY集合变量。

（2）以NOCASCADE方式调用TRANSACTION_BACKOUT。如果报错，再从另外3种方式中选择一个调用BACKOUT_TRANSACTION。

（3）查看闪回事务操作的报告。

（4）最后决定提交或回滚。