分区drop对本地分区索引的影响

sqysl

bisal 发表于 2015-2-23 21:48
1. “update indexes和alter index online都可以增删改查操作，但会影响性能”
这个怎么评估呢？或者说怎 ...

嗯，谢谢你的实验，从来没想过使用，也从来没用过不包括分区键的local index作主键。
抛开这个问题，我们可以拓展一下，就索引本身而言，没有哪个索引可以保证数据的唯一性，主键或唯一性索引之所以能保证唯一性，是因为除了创建索引外，还创建了约束，所谓约束，无非类似触发的一些代码，当新值要进入表时，约束会查询表中是否已经存在这个新值，如果存在，就抛出错误，否则，就允许进入表。假如有个分区表，当有新值进入时，主键约束会查表里的值，如果没索引，就得进行全表扫描以确定是否已存在这个新值，不用说，每进入一个新值就得扫全表一遍，实际中是不可用的；如果有不包括分区键的local索引，那么约束就得扫描所有的索引分区，以确定表里是否存在这个新值；如果有包括分区键的local索引，那么，约束只需扫描索引的当前分区就可以了，不用说，最后一种情况是性能最好的，所以，oracle禁用了前两种情况的发生，以确保不发生性能等问题。
个人观点，仅供参考。

sqysl

bisal 发表于 2015-2-25 16:36
嗯，说明，这两种看似online的操作，还是会有锁，只是理论上持有的时间很快，但既然会持有，那就存在您说 ...

其实，在一个繁忙的数据库里，锁时时刻刻、无处不在，因为数据库的核心机制就是锁，通过锁来保证并发的有序化，所以，大可不必谈“谈锁色变”，我也经常向现场的运维和DBA这么告诫和纠正，关键是看锁是否正常。
实践中，这两个操作在负载很重的生产库上实施过，当然是在负载低峰时，并没发现像你担心的那些问题。
此外，个人认为，锁等待和所谓的"hang"住，是两种情况，锁等待只不过是等待共同资源的相关会话等待而已，其他会话还是正常的；而所谓的"hang"住，是整个系统“frozen”的情况，后者比前者严重的多，发生的几率也低的多，现实中，很多人把普通的锁等待也称为"hang"住，其实是不合适的。

bisal

sqysl 发表于 2015-2-27 11:07
其实，在一个繁忙的数据库里，锁时时刻刻、无处不在，因为数据库的核心机制就是锁，通过锁来保证并发的有 ...

谢谢您的纠正。