Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 6 ■ LOCKING AND LATCHING 197 DEPTNO DNAME BLOCKNO ORA_ROWSCN ---------- -------------- ---------- ---------- 10 ACCOUNTING 20972 34676029 20 RESEARCH 20972 34676029 30 SALES 20973 34676029 40 OPERATIONS 20973 34676029 And sure enough, that is what we observe in this case. So, let’s update the row where DEPTNO = 10 is on block 20972: ops$tkyte@ORA10G> update dept 2 set dname = lower(dname) 3 where deptno = 10; 1 row updated. ops$tkyte@ORA10G> commit; Commit complete. What we’ll observe next shows the consequences of ORA_ROWSCN being tracked at the block level. We modified and committed the changes to a single row, but the ORA_ROWSCN values of both of the rows on block 20972 have been advanced: ops$tkyte@ORA10G> select deptno, dname, 2 dbms_rowid.rowid_block_number(rowid) blockno, 3 ora_rowscn 4 from dept; DEPTNO DNAME BLOCKNO ORA_ROWSCN ---------- -------------- ---------- ---------- 10 accounting 20972 34676046 20 RESEARCH 20972 34676046 30 SALES 20973 34676029 40 OPERATIONS 20973 34676029 It would appear to anyone else that had read the DEPTNO=20 row that it had been modified, even though it was not. The rows on block 20973 are “safe”—we didn’t modify them, so they did not advance. However, if we were to update either of them, both would advance. So the question becomes how to modify this default behavior. Well, unfortunately, we have to re-create the segment with ROWDEPENDENCIES enabled. Row dependency tracking was added to the database with Oracle9i in support of advanced replication to allow for better parallel propagation of changes. Prior to Oracle 10g, its only use was in a replication environment, but starting in Oracle 10g we can use it to implement an effective optimistic locking technique with ORA_ROWSCN. It will add 6 bytes of overhead to each row (so it is not a space saver compared to the do-it-yourself version column) and that is, in fact, why it requires a table re-create and not just a simple ALTER TABLE: the physical block structure must be changed to accommodate this feature. Let’s rebuild our table to enable ROWDEPENDENCIES. We could use the online rebuild capabilities in DBMS_REDEFINITION (another supplied package) to do this, but for something so small, we’ll just start over:
198 CHAPTER 6 ■ LOCKING AND LATCHING ops$tkyte@ORA10G> drop table dept; Table dropped. ops$tkyte@ORA10G> create table dept 2 (deptno, dname, loc, data, 3 constraint dept_pk primary key(deptno) 4 ) 5 ROWDEPENDENCIES 6 as 7 select deptno, dname, loc, rpad('*',3500,'*') 8 from scott.dept; Table created. ops$tkyte@ORA10G> select deptno, dname, 2 dbms_rowid.rowid_block_number(rowid) blockno, 3 ora_rowscn 4 from dept; DEPTNO DNAME BLOCKNO ORA_ROWSCN ---------- -------------- ---------- ---------- 10 ACCOUNTING 21020 34676364 20 RESEARCH 21020 34676364 30 SALES 21021 34676364 40 OPERATIONS 21021 34676364 We’re back where we were before: four rows on two blocks, all having the same initial ORA_ROWSCN value. Now when we update DEPTNO=10 ops$tkyte@ORA10G> update dept 2 set dname = lower(dname) 3 where deptno = 10; 1 row updated. ops$tkyte@ORA10G> commit; Commit complete. we should observe the following upon querying the DEPT table: ops$tkyte@ORA10G> select deptno, dname, 2 dbms_rowid.rowid_block_number(rowid) blockno, 3 ora_rowscn 4 from dept; DEPTNO DNAME BLOCKNO ORA_ROWSCN ---------- -------------- ---------- ---------- 10 accounting 21020 34676381 20 RESEARCH 21020 34676364 30 SALES 21021 34676364 40 OPERATIONS 21021 34676364
- Page 192 and 193: CHAPTER 4 ■ MEMORY STRUCTURES 147
- Page 194 and 195: CHAPTER 4 ■ MEMORY STRUCTURES 149
- Page 196 and 197: CHAPTER 4 ■ MEMORY STRUCTURES 151
- Page 198 and 199: CHAPTER 4 ■ MEMORY STRUCTURES 153
- Page 200 and 201: CHAPTER 5 ■ ■ ■ Oracle Proces
- Page 202 and 203: CHAPTER 5 ■ ORACLE PROCESSES 157
- Page 204 and 205: CHAPTER 5 ■ ORACLE PROCESSES 159
- Page 206 and 207: CHAPTER 5 ■ ORACLE PROCESSES 161
- Page 208 and 209: CHAPTER 5 ■ ORACLE PROCESSES 163
- Page 210 and 211: CHAPTER 5 ■ ORACLE PROCESSES 165
- Page 212 and 213: CHAPTER 5 ■ ORACLE PROCESSES 167
- Page 214 and 215: CHAPTER 5 ■ ORACLE PROCESSES 169
- Page 216 and 217: CHAPTER 5 ■ ORACLE PROCESSES 171
- Page 218 and 219: CHAPTER 5 ■ ORACLE PROCESSES 173
- Page 220 and 221: CHAPTER 5 ■ ORACLE PROCESSES 175
- Page 222 and 223: CHAPTER 5 ■ ORACLE PROCESSES 177
- Page 224 and 225: CHAPTER 5 ■ ORACLE PROCESSES 179
- Page 226 and 227: CHAPTER 5 ■ ORACLE PROCESSES 181
- Page 228 and 229: CHAPTER 6 ■ ■ ■ Locking and L
- Page 230 and 231: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 232 and 233: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 234 and 235: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 236 and 237: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 238 and 239: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 240 and 241: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 244 and 245: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 246 and 247: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 248 and 249: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 250 and 251: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 252 and 253: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 254 and 255: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 256 and 257: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 258 and 259: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 260 and 261: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 262 and 263: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 264 and 265: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 266 and 267: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 268 and 269: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 270 and 271: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 272 and 273: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 274 and 275: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 276 and 277: CHAPTER 7 ■ ■ ■ Concurrency a
- Page 278 and 279: CHAPTER 7 ■ CONCURRENCY AND MULTI
- Page 280 and 281: CHAPTER 7 ■ CONCURRENCY AND MULTI
- Page 282 and 283: CHAPTER 7 ■ CONCURRENCY AND MULTI
- Page 284 and 285: CHAPTER 7 ■ CONCURRENCY AND MULTI
- Page 286 and 287: CHAPTER 7 ■ CONCURRENCY AND MULTI
- Page 288 and 289: CHAPTER 7 ■ CONCURRENCY AND MULTI
- Page 290 and 291: CHAPTER 7 ■ CONCURRENCY AND MULTI
198<br />
CHAPTER 6 ■ LOCKING AND LATCHING<br />
ops$tkyte@ORA10G> drop table dept;<br />
Table dropped.<br />
ops$tkyte@ORA10G> create table dept<br />
2 (deptno, dname, loc, data,<br />
3 constraint dept_pk primary key(deptno)<br />
4 )<br />
5 ROWDEPENDENCIES<br />
6 as<br />
7 select deptno, dname, loc, rpad('*',3500,'*')<br />
8 from scott.dept;<br />
Table created.<br />
ops$tkyte@ORA10G> select deptno, dname,<br />
2 dbms_rowid.rowid_block_number(rowid) blockno,<br />
3 ora_rowscn<br />
4 from dept;<br />
DEPTNO DNAME<br />
BLOCKNO ORA_ROWSCN<br />
---------- -------------- ---------- ----------<br />
10 ACCOUNTING 21020 34676364<br />
20 RESEARCH 21020 34676364<br />
30 SALES 21021 34676364<br />
40 OPERATIONS 21021 34676364<br />
We’re back where we were before: four rows on two blocks, all having the same initial<br />
ORA_ROWSCN value. Now when we update DEPTNO=10<br />
ops$tkyte@ORA10G> update dept<br />
2 set dname = lower(dname)<br />
3 where deptno = 10;<br />
1 row updated.<br />
ops$tkyte@ORA10G> commit;<br />
Commit complete.<br />
we should observe the following upon querying the DEPT table:<br />
ops$tkyte@ORA10G> select deptno, dname,<br />
2 dbms_rowid.rowid_block_number(rowid) blockno,<br />
3 ora_rowscn<br />
4 from dept;<br />
DEPTNO DNAME<br />
BLOCKNO ORA_ROWSCN<br />
---------- -------------- ---------- ----------<br />
10 accounting 21020 34676381<br />
20 RESEARCH 21020 34676364<br />
30 SALES 21021 34676364<br />
40 OPERATIONS 21021 34676364