Learning is not a spectator sport

April 29, 2013

Its not about the outage

Filed under: Uncategorized — connormcdonald @ 10:00 pm

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".

About these ads

9 Comments »

  1. Connor,

    Yours experience exactly repeats mine. Some time ago I have reported an obvious bug related to the extended statistics. The only thing I have been expecting from MOS analyst is to log a bug. Instead of that I have got a ton of unrelated suggestions and questions. The person on the other end ether wasn’t skilled enough or didn’t want to do his job (I think it was the first option).

    Anyway I did follow up with his manager and made sure that there have been actions taken to improve the situation.
    Did you?

    YuryVelikanov

    Comment by Yury — April 30, 2013 @ 5:56 pm

  2. And you are making a very good point. Unfortunately too often service providers don’t listen to their customers :(

    Comment by Yury — April 30, 2013 @ 6:17 pm

  3. One other thought on the topic. The quality of Oracle Support wasn’t great since I remember myself (~15 years or so). Yes there have been a good engineers who provided a good response to SRs I have opened. However unfortunately in most of the cases the quality wasn’t great. I think Oracle just save a bit on costs of engineers and provides just enough to call the service a Support. I didn’t have extensive experience with any other vendors to compare with. But I would like to hope that there are better Support somewhere else. Oracle just save money on good service.

    Comment by Yury — April 30, 2013 @ 6:42 pm

    • I disagree on the quality of support being bad in the past. I remember giving a talk to a user group saying “thank god you are not using Baan (remember that) or Siebel, because Oracle Support lives it for dead”…and I honestly believed that. There were names on the Metalink forums (Helen and Ken where are you??!?!?!) where you knew that a response from them would be informed, honest and spot on for content.

      SR (or TAR’s in those days) were similar. Yes, a little bit of the satndard questions (alert log please etc), but then you got at least well thought out responses and questions….

      You can *still* get that quality – but normally that comes after escalation, ranting, anger, etc etc etc…..Its a reinforcement of the “yell louder to get results”…

      Comment by connormcdonald — April 30, 2013 @ 8:25 pm

  4. In case you want to know, It works properly on AIX Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production

    SQL>

    select segment_name, partition_name, bytes from user_segments where segment_name=’IX';
    SEGMENT_NAME PARTITION_NAME
    ——————————————————————————— —————-
    IX SYS_P4041
    IX SYS_P4042
    IX SYS_P4043
    IX SYS_P4044

    4 filas seleccionadas.

    SQL>

    alter index IX modify partition SYS_P4041 unusable;

    ‚ēźndice modificado.

    SQL>

    select segment_name, partition_name, bytes from user_segments where segment_name=’IX';
    SEGMENT_NAME PARTITION_NAME
    ——————————————————————————— —————-
    IX SYS_P4042
    IX SYS_P4043
    IX SYS_P4044

    3 filas seleccionadas.

    Comment by Joaquin Gonzalez — April 30, 2013 @ 9:09 pm

    • Thanks – and therein lies the frustration.because it probably means:

      Either the support person on the SR

      a) could not be bothered trying my testcase
      b) could not understand what was being asked
      c) did not have access to an 11.2.0.3 AIX install

      Any of the three alternatives do not inspire confidence

      Comment by connormcdonald — April 30, 2013 @ 9:49 pm

  5. [...] Connon McDonald says that its not about the outage, but…. [...]

    Pingback by Latest data Industry news round up, Log Buffer #318 — May 3, 2013 @ 7:51 pm

  6. I completely agree with you, and that is way I prefer to to only open an SR as last resource.

    BTW, just don’t forget to give a negative feedback in the email arrives!

    Pedro

    Comment by Pedro — May 3, 2013 @ 9:09 pm

  7. I suppose the final nail in the coffin was as follows…

    After seeing Joaquins post, I installed 11.2.0.3 on our server and re-tested, and yes, the problem is fixed in 11.2.0.3.

    Hence I logged on to MOS and closed the SR with the the results above. When I closed the SR, you can choose a reason, and I chose: Resolved myself

    So I was a little surprised when an update was added to my SR, asking: “Is this resolved ?” “Can you explain how you resolved it ?”

    sigh….

    Comment by connormcdonald — May 3, 2013 @ 10:46 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The WordPress Classic Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 79 other followers

%d bloggers like this: