Chinaunix

标题: oracle表移动表空间之后primary key仍然有效？？？ [打印本页]

作者: 蓦然princes 时间: 2014-05-28 23:29
标题: oracle表移动表空间之后primary key仍然有效？？？
本帖最后由蓦然princes 于 2014-05-28 23:29 编辑

今天做实验遇到个问题想请教一下老鸟。

实验环境：oracle11g R2.

问题：我将表t（id int primary key）从example表空间移到users表空间。发现primary key居然能用，没有失效，按道理说，创建主键约束时会创建一个唯一索引（通过use_objects 可以查到），那表从一个表空间移到另一个表空间索引就失效了啊，怎么primary key还能有效呢？？？
求老鸟指点~~

作者: jackson198574 时间: 2014-05-29 08:45
你是通过什么方式移动的？

作者: 蓦然princes 时间: 2014-05-29 09:51
用alter table t move。。我又做了一次实验。对不起，不是主键仍然可用，提示信息是所操作的index处于不可用状态。。这下对了。回复 2# jackson198574

作者: jackson198574 时间: 2014-05-29 13:46
回复 3# 蓦然princes

加油！保持精益求精的态度和实验验证的风格！~~~

作者: www_xylove 时间: 2014-05-29 20:49
学习。

作者: 蓦然princes 时间: 2014-05-30 23:03
谢谢鼓励！！！我最近有个关于scn号的问题，老是想不明白，网上的也说的不全。想请问下一下您：

问题：
有没有这样一种情况：一个事务很大，从事务发生到最后提交没有发生日志切换。此时在log buffer中产生了很多的log，当然lgwr会不停的向log file中写，并且不断的增加scn号。
在这个过程中checkpoint事件发生，此时DBWn进程会将已近写入到log file中的日志对应的data buffer中的block 写入到data file中。写完之后ckpt进程会在控制文件和数据文件头部增加scn号（记为1001）。（这些数据只是整个事务产生的一部分）

此时，整个事务还没有commit。这时instance垮掉了。重启instance 进行recovery。

按照recovery机制。控制文件中的scn会和数据文件头部的start scn号进行对比，由于不是正常关机，所以，控制文件中的last scn会无穷大，和数据文件头部的start scn（1001）不一致。然后在log file中将scn （1001）之后的所有日志恢复（roll forward）。

疑问：这里将scn（1001）之后的日志文件roll forward，但是scn（1001）之前的那些日志对应的数据虽然写入到了数据文件，但是那些是这个事务没有提交的部分啊？恢复的log file中scn（1001）以后的日志不包含1001之前的数据对应的日志，怎么进行 rollback啊？？？？

回复 4# jackson198574

作者: jackson198574 时间: 2014-06-04 16:48
回复 6# 蓦然princes

Undo表空间存有之前的信息副本呀。

作者: jackson198574 时间: 2014-06-04 16:48
回复 6# 蓦然princes

最近工作特别忙，没及时回复，抱歉啊兄弟。

作者: 蓦然princes 时间: 2014-06-07 00:01
工作重要啊，回帖抽空就行了，不用打扰工作的。回帖本来就是一种无偿回报社会帮助他人的行为，所以很谢谢你的帮助。回复 8# jackson198574

作者: jackson198574 时间: 2014-06-07 11:44
回复 9# 蓦然princes

谢谢理解！

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)