A story about OFA and other Standards

Today Cary Millsap posted his second story on this new blog site carymillsap.blogspot.com called: “How the OFA Began, Part 1“. What Cary’s story actually triggered on my part, was doing a small trip back into memory lane. This was probably also caused because today I was working with one of my “newbie” colleagues. He won’t like the term when he reads it, but in my mind this is still the case. The guy has a big advantage, he is keen and he is eager. He has also a disadvantage; he is eager. He reminds me a little at when I started working in the IT DBA field, a promising raw diamond, that still has to be cut. So today, before I knew that Cary would post his piece about OFA, I told him about OFA. Showed him the link to the OFA Hotsos site (thank you Doug) and printed it out for him. I wanted to let him realize that a lot of stuff out there in the DBA world was there for a reason and shouldn’t be taken for granted. Also that there was more to those “standards” then he probably knew or realized.

I wonder if some of those “new kids on the block” don’t get tired of every change in Oracle’s OFA structure the moment they release new database software. As Doug promoted during his presentation on UKOUG, having a (aka one) standard has a lot of advantages. I don’t like the phrase “self documenting”, but keeping a standard has it advantages for people that follow up after you have set the whole thing up. If you agree on a standard (so also agree on the reasons behind it), it makes your life easier. So if every one of those “new kids on the block” comes up with a OFA kind of thingy, there is hope for him (he thought about it). Also this will be a disappointing event for him or her, when one of the “old guys on the block” will guide him to the original whitepaper.

This lead to another, so today my enthusiastic story telling went from OFA to SAME, which is only promoted by Oracle as “the truth, the whole truth and nothing but the truth” since Oracle 10 (I think) and was for me old news since I was thought this by a good mentor, so implementing it since Oracle 7 / 8. My story went on by telling about “the hoax of the introduction of locally managed tablespaces”. Yeah, there are great neat things about locally managed tablespaces. But the story behind it, avoiding segmentation, is as old as… My great mentor from that time, thought me the ins and outs of being aware of equally uniform segmented dictionary tablespaces and although I forgot (aka became lazy) the exact sizes for each uniform segment per tablespace and where I can find the whitepaper about this, this principle still stands. The idea behind uniform segmented dictionary tablespaces (you could nowadays implement the same principles via the uniform locally managed tablespaces) was that fragmentation was limited to a minimum. Every table / index / partition, etc, according to its growth and form, expectations about sizing could be made regarding storage in its designated uniform segmented tablespace. I wonder if this still is a best practice nowadays.

While I write this I also wonder why this (“segmentation”) is an issue again? Fragmentation / segmentation, I mean (yep, this is an ironic remark) in great tools like DB Console or Oracle Enterprise Manager. When I started in the Oracle 7 days, there was a maximum limit to the upper extent limit of an physical database object, because this was limited by the db_block_size you had chosen during database creation. A db_block_size of 2048 would allow a maximum of 121 extents = (db_block_size/16)-7. When the limit was lifted via a software solution, the marketing machine announced that fragmentation was no issue at all anymore (“don’t bother! we have it solved!”), so I wonder why it (segmentation) shows up again in those fancy GUI’s with warning signs like “do something about it!”, “reorganize it”. When did the problem go away in the first place? As once one of the dutch Oakies told me: “Marco, nothing has really changed. Only that we become older and make more money for doing the stuff we did ages ago, that is, solving old problems”. Apparently one thing is more needed then ever and that is that we tell, to everyone who wants to hear it, the old standards that once where already created by some of those people out there. So I hope, my newbie, picked up something today or starts hopefully wondering why someone can get that enthusiastic about those “simple” things.

Related whitepapers

Marco Gralike Written by:


  1. February 14

    “nothing has really changed. Only that we become older and make more money for doing the stuff we did ages ago, that is, solving old problems”

    Ha, too true 😉 I know the technology marches on, but people’s ability to shoot themselves in the foot is reliably consistent.

  2. February 14

    I my mind the mentioned whitepaper is “to clean” (or I became a lot smarter – nahh, I don’t think so…) in its explanation of the issues… although while checking it, the time frame looks correct (7.3 / 8.0)

    Doug, Thanks.

    I will put this one in a short list at the end of the post as well.

  3. February 14

    I don’t think it’s the original that we would have both read. It’s a later version (the title has some extra words on the end, for example) but I think it’s the same authors addressing the same issues.

Comments are closed.