错误删除Its not about the outage
发一下牢骚和主题无关：
我的Oracle持支在Australian工作日的半夜有当相长冗的停运。
但是我不会写客博录记这个。我从很多客户网站中学到一件事：人们会明确然后记忘这些事，比如停运，错误，溃崩，或者仅仅是一般的软件错误，只要你满充情激的取得客户的收益，你就不会惰懒或者草率的从错误中学习。
但是有一件事，或许是最主要的，就是客户绝不会容忍，就是当你不听他们对你的帮助。
这就是MOS正在受遭的—不是从停运来，不是从错误来，但是从聆听来…
我录记了这个系统修复工程师的语录：
Problem: Making index partition unusable does not free underlying segment
问题：应用引索划分对释放础基段没有作用
测试用例：
SQL> sho parameter deferred
NAME TYPE VALUE
------------------------------------ ----------- ----------------------------------
deferred_segment_creation boolean TRUE
SQL> 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 d
SQL> select segment_name, partition_name, bytes from user_segments;
SEGMENT_NAME PARTITION_NAME BYTES
---------------------------------------- ------------------------------ ----------
T SYS_P42997 8388608
T SYS_P42998 8388608
T SYS_P42999 8388608
T ARCH_P0 8388608
T SYS_P42996 8388608
IX ARCH_P0 65536
IX SYS_P43000 65536
IX SYS_P43001 65536
IX SYS_P43002 65536
IX SYS_P43003 65536
10 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 8388608
T SYS_P42998 8388608
T SYS_P42999 8388608
T ARCH_P0 8388608
T SYS_P42996 8388608
IX ARCH_P0 65536
IX SYS_P43000 65536
IX SYS_P43001 65536
IX SYS_P43002 65536
IX SYS_P43003 65536
10 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 you
And 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 segment
Test Case:
SQL> sho parameter deferred
NAME TYPE VALUE
------------------------------------ ----------- ----------------------------------
deferred_segment_creation boolean TRUE
SQL> 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 d
SQL> select segment_name, partition_name, bytes from user_segments;
SEGMENT_NAME PARTITION_NAME BYTES
---------------------------------------- ------------------------------ ----------
T SYS_P42997 8388608
T SYS_P42998 8388608
T SYS_P42999 8388608
T ARCH_P0 8388608
T SYS_P42996 8388608
IX ARCH_P0 65536
IX SYS_P43000 65536
IX SYS_P43001 65536
IX SYS_P43002 65536
IX SYS_P43003 65536
10 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 8388608
T SYS_P42998 8388608
T SYS_P42999 8388608
T ARCH_P0 8388608
T SYS_P42996 8388608
IX ARCH_P0 65536
IX SYS_P43000 65536
IX SYS_P43001 65536
IX SYS_P43002 65536
IX SYS_P43003 65536
10 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 space
For 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客博] |
文章结束给大家分享下程序员的一些笑话语录： 人工智能今天的发展水平：8乘8的国际象棋盘其实是一个体现思维与创意的强大媒介。象棋里蕴含了天文数字般的变化。卡斯帕罗夫指出，国际象棋的合法棋步共有1040。在棋局里每算度八步棋，里面蕴含的变化就已经超过银河系里的繁星总数。而地球上很少有任何数量达到这个级别。在金融危机之前，全世界的财富总和大约是1014人民币，而地球人口只有1010。棋盘上，所有可能的棋局总数达到10120，这超过了宇宙里所有原子的总数！经典语录网