Home » RDBMS Server » Performance Tuning » Shameless plug
Shameless plug [message #617949] Sat, 05 July 2014 00:38 Go to next message
rleishman
Messages: 3728
Registered: October 2005
Location: Melbourne, Australia
Senior Member
Hi folks. I just published a Performance Tuning article on the main OraFAQ page. I know the Index Rebuild debate is old and tired, but I think I found something new and interesting to say about it (whilst reprising much of the old, tired stuff)

Have a read, provide feedback if you like.

http://www.orafaq.com/node/2903

Ross Leishman
Re: Shameless plug [message #617954 is a reply to message #617949] Sat, 05 July 2014 05:25 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
Some years ago, I suggested developing a book based on OraFAQ members' articles and experience, http://www.orafaq.com/forum/m/495359/?srch=book#msg_495359
The project never got anywhere. If I try again, would you (or anyone else) be interested? I think some of your blog articles are excellent material.
Re: Shameless plug [message #617955 is a reply to message #617954] Sat, 05 July 2014 05:40 Go to previous messageGo to next message
rleishman
Messages: 3728
Registered: October 2005
Location: Melbourne, Australia
Senior Member
I know some folk who have written books (I know you have as well, John, so you may speak with considerably more authority than me) and I haven't heard the process described as a very rewarding one. I understand that you will never recoup the blood, sweat and tears in terms of profit; and the process of editing a collaborative work to get a common voice and style would be torturous.

The self-publishing approach via ebook or something like Amazon print-on-demand services has some appeal, but then there are problems like promotion and publicising that are largely avoided if you can get published with O'Reilley or Oracle Press. Besides, since there is (probably) no money in it, the biggest reward is career advancement through promoting the brand that is your own name - and a recognised publishing label helps with that.

I don't think I have made a point except ... well it seems like an awful lot of work.
Re: Shameless plug [message #617974 is a reply to message #617955] Sat, 05 July 2014 17:46 Go to previous messageGo to next message
rleishman
Messages: 3728
Registered: October 2005
Location: Melbourne, Australia
Senior Member
Many thanks John and Lalit for your kind words on the article. If these ever went into a best-of book, John's opening semtence would be on the back cover above the blurb.
Nice to know somebody read The Bitmap Conspiracy too, I think it might have been a bit long for a mainstream audience.

Ross Leishman
Re: Shameless plug [message #617983 is a reply to message #617974] Sun, 06 July 2014 06:07 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
Ross, your latest blog comment has finally kicked me into documenting a test of hash clusters compared with heap tables for concurrency, also on the blog. Perhaps I'll get around to doing the same thing for reverse key indexes some time.

--update:Oh no! Just noticed a bad mistake! I have de-published myself.

[Updated on: Sun, 06 July 2014 06:19]

Report message to a moderator

Re: Shameless plug [message #617990 is a reply to message #617983] Sun, 06 July 2014 07:48 Go to previous message
rleishman
Messages: 3728
Registered: October 2005
Location: Melbourne, Australia
Senior Member
Uh oh! I hope I didn't sound dismissive of the idea ... just wary. It is a fascinating use case for clusters (hash or index) and definitely warrants some discovery work, so I applaud your research and hope to see you get it posted. I looked at the draft and it seems pretty good to me. I would like to see some timings added for context - not because I disbelieve them, but because a measurable example is a more powerful one.

Here's something interesting: The following is from the About Clusters section of the Administrators guide:
Quote:
Because clusters store related rows of different tables together in the same data blocks, properly used clusters offer two primary benefits:

  • Disk I/O is reduced and access time improves for joins of clustered tables.
  • The cluster key is the column, or group of columns, that the clustered tables have in common. You specify the columns of the cluster key when creating the cluster. You subsequently specify the same columns when creating every table added to the cluster. Each cluster key value is stored only once each in the cluster and the cluster index, no matter how many rows of different tables contain the value.Therefore, less storage might be required to store related table and index data in a cluster than is necessary in non-clustered table format.

That second example on space savings for cluster columns looks like it came straight out of a 1966 CICS/COBOL Best Practice manual for storing YYMMDD dates.

It seems incredible that they can publish that and ignore the possibility of distributing INSERT traffic.

Given that Reverse Key indexes seem designed to handle the problem in indexes, I wonder why there is no tailored solution for tables?

Ross Leishman
Previous Topic: I/O calibration
Next Topic: AWR and ASH report analyze
Goto Forum:
  


Current Time: Thu Mar 28 05:13:05 CDT 2024