Its not about the outage

        我的Oracle支持在Australian工作日的中午有相当冗长的停运。

 

         但是我不会写博客记录这个。我从很多客户网站中学到一件事：人们会明白然后忘记这些事，比如停运，错误，崩溃，或者仅仅是普通的软件错误，只要你充满激情的获得客户的收益，你就不会懒惰或者轻率的从错误中学习。

 

        但是有一件事，或许是最重要的，就是客户绝不会容忍，就是当你不听他们对你的帮助。

 

        这就是MOS正在遭受的—不是从停运来，不是从错误来，但是从倾听来…

      

        我记录了这个系统修复工程师的语录：

        

        问题：使用索引划分对释放基础段没有作用

 

        测试用例：

 

SQL> sho parameter deferredNAME TYPE VALUE------------------------------------ ----------- ----------------------------------deferred_segment_creation boolean TRUESQL> drop table T purge;Table dropped.SQL> create table T ( x timestamp, y int)  2  PARTITION BY RANGE (x)  3  INTERVAL( NUMTODSINTERVAL(1,'DAY'))  4  (  5  PARTITION ARCH_P0 VALUES LESS THAN (TIMESTAMP' 2009-01-01 00:00:00')  6  )  7  /Table created.SQL> insert into T values ('01-APR-13',1);SQL> insert into T values ('02-APR-13',1);SQL> insert into T values ('03-APR-13',1);SQL> insert into T values ('04-APR-13',1);SQL> create index IX on T ( x ) local;Index created.SQL> col partition_name new_value dSQL> select segment_name, partition_name, bytes from user_segments;SEGMENT_NAME PARTITION_NAME BYTES---------------------------------------- ------------------------------ ----------T SYS_P42997 8388608T SYS_P42998 8388608T SYS_P42999 8388608T ARCH_P0 8388608T SYS_P42996 8388608IX ARCH_P0 65536IX SYS_P43000 65536IX SYS_P43001 65536IX SYS_P43002 65536IX SYS_P43003 6553610 rows selected.SQL> alter index IX modify partition &&d unusable;Index altered.SQL> select segment_name, partition_name, bytes from user_segments;SEGMENT_NAME PARTITION_NAME BYTES---------------------------------------- ------------------------------ ----------T SYS_P42997 8388608T SYS_P42998 8388608T SYS_P42999 8388608T ARCH_P0 8388608T SYS_P42996 8388608IX ARCH_P0 65536IX SYS_P43000 65536IX SYS_P43001 65536IX SYS_P43002 65536IX SYS_P43003 6553610 rows selected.

 

         在人们评判之前我不会展示版本和平台，记住你在记录SR，这些事被提供作为SR被记录。在这种情况下，平台是AIX，版本是11.2.0.2。我也发布一种情况在SR在版本为11.2.0.3的Linux平台下，段在索引划分被设置成无法使用的情况下的确被正确的删除。

      

         这是细小的测试用例，我的查询也很简单 – 平台或者版本或者他们二者真的是问题吗？

      

         但是这篇文章是关于倾听的…

 

         第一条对SR的回复：

 

         你的问题是这个：“在Alter Table Move之后，无法使用的索引段在DBA_SEGMENTS仍然有”

      

         好…我不这样认为。或许是因为这个测试用例没有提及alter-table-move。

      

         我通过SR更新得到这个结果。

      

        第二条对SR的回复：

             

         你可以删除这个分区，然后回收空闲空间

      

        对于初学者，歧义在于有风险的建议。他们真的是说删除这个表分区或者索引分区？或许我的下一条SR是“我怎样能够恢复我刚才删除的数据？”

      

       第二点，没有解决最原始的请求。

      

         因此我很开心接收MOS停运发生…这些事情在IT世界里做。我们在试着避免他们，但是他们仍然会发生。

      

        但是当信息技术里的非技术的组件比如简单优秀的倾听技巧依然遭受平常的“停运”是很伤心的一件事。

 

My Oracle Support had a fairly lengthy outage today right in the middle of the Australian business day.But I’m not going to blog about that.  One thing I’ve learnt from many client sites is that people will understand and forgive things like outages, or errors, or crashes, or just plain wrong software, as long its evident that you are passionately working for the benefit of the user, that you were not lazy or flippant or learning from mistakes…But one thing, perhaps the biggest thing, that customers will NOT tolerate, is when you don’t listen to what they’re trying to tell youAnd that’s where MOS is suffering – not from outages, not from errors, but from not listening….I logged this SR:Problem: Making index partition unusable does not free underlying segmentTest Case:SQL> sho parameter deferredNAME TYPE VALUE------------------------------------ ----------- ----------------------------------deferred_segment_creation boolean TRUESQL> drop table T purge;Table dropped.SQL> create table T ( x timestamp, y int)  2  PARTITION BY RANGE (x)  3  INTERVAL( NUMTODSINTERVAL(1,'DAY'))  4  (  5  PARTITION ARCH_P0 VALUES LESS THAN (TIMESTAMP' 2009-01-01 00:00:00')  6  )  7  /Table created.SQL> insert into T values ('01-APR-13',1);SQL> insert into T values ('02-APR-13',1);SQL> insert into T values ('03-APR-13',1);SQL> insert into T values ('04-APR-13',1);SQL> create index IX on T ( x ) local;Index created.SQL> col partition_name new_value dSQL> select segment_name, partition_name, bytes from user_segments;SEGMENT_NAME PARTITION_NAME BYTES---------------------------------------- ------------------------------ ----------T SYS_P42997 8388608T SYS_P42998 8388608T SYS_P42999 8388608T ARCH_P0 8388608T SYS_P42996 8388608IX ARCH_P0 65536IX SYS_P43000 65536IX SYS_P43001 65536IX SYS_P43002 65536IX SYS_P43003 6553610 rows selected.SQL> alter index IX modify partition &&d unusable;Index altered.SQL> select segment_name, partition_name, bytes from user_segments;SEGMENT_NAME PARTITION_NAME BYTES---------------------------------------- ------------------------------ ----------T SYS_P42997 8388608T SYS_P42998 8388608T SYS_P42999 8388608T ARCH_P0 8388608T SYS_P42996 8388608IX ARCH_P0 65536IX SYS_P43000 65536IX SYS_P43001 65536IX SYS_P43002 65536IX SYS_P43003 6553610 rows selected.Now before people criticise that I didn’t show version and platform, remember that in logging an SR, these things are provided as the SR is logged.  In this case, the platform is AIX and the version is 11.2.0.2.  I also posted a case into the SR showing the under 11.2.0.3 on Linux, the segment is indeed correctly dropped when the index partition is set to unusable.Its a trivial test case, and my inquiry was simple – is it platform or version or both that is the issue.But this post is about listening…First response to the SR:Your problem is this: "Unusable Index Segment Still Exists in DBA_SEGMENTS for Alter Table Move"Well…I dont think so. Probably because the test case makes no mention of alter-table-move. I point this out via an SR update.Second response to the SR:You can drop the partition to reclaim free spaceFor starters, the ambiguity is risky advice.  Do they mean drop the table partition or the index partition ?  Might my next SR be "how can I recover the data I just dropped ?"Secondly, its not addressing the original request.So I’m more than happy to accept that an MOS outage happened….these things do in the IT world.  We try to avoid them, but they happen.But its sad when the NON-technical components of IT, that of simple good listening skills also suffer regular "outages".

        http://www.oaktable.net/content/its-not-about-outage

 

 

 @Wentasy 博文仅供参考，欢迎大家来访。如有错误之处，希望批评指正。原创博文如需转载请注明出处，谢谢 :) [CSDN博客]