Writing a book.... Part 2

Greetings all...

So I'm in the middle of my new GoldenGate book. I've written chapters 3,4, and 5 and currently I'm working on Chapter 2. I know, that might not make sense but it did for me... :) At any rate, I've found GoldenGate to be a great little replication product...

I really think that this book is going to be a dynamite book and I think that GoldenGate is going to really come into the Enterprise more and more as time goes on for a number of reasons.

Don't Believe Everything You Read

When you write about a product you come across certain subtitles and problems that kind of make you wonder. In the latest case I was writing about the privileges that are required by the GoldenGate administrator account. I found a bit of a documentation error in that it does not include issuing a grant of the alter any table privilege (or alter table if you prefer) to the GoldenGate administrator account. This privilege is required to be able to issue the GoldenGate add trandata command which enables supplemental logging on a specific object within the database, a requirement for GoldenGate replication. Curious that this was missing.

The Concept of Least Privilege in Oracle Database Security
Even more curious is how my competition handled this problem and this leads to a discussion on the concept of least privilege and how even the most innocent of things can be a really bad. idea. In the data realm, security is strengthened by the notion of least privilege which is where a specific user account is given only the exact privileges it needs. In this day of hacking, break-in's and SQL injection, locking down the database is critical. All to often though, because it's easier, DBA's will grant administrative privileges to accounts, without considering the risks that this entails. The thought seems to be that in granting the DBA role to an account, we are saving time and money by not drilling down into the privileges that are really needed and only granting those specifically required privileges. Of course, we assume just because we have not been hacked yet, that we are immune from such nastiness and as a result we lazily grant DBA to anyone.

Maybe it's not hackers at all we need to protect ourselves from... maybe it's a software bug or design flaw (if you prefer) that we need to protect ourselves from. At any rate, granting DBA privileges willy nilly is just a really bad bad idea. There is a great deal of discussion on least privilege on the internet, and I think the concept is really pretty obvious to anyone of moderate intelligence. At least .... you would think.


Books are things that people read to learn how to do things, and how to do them right. Now, we all make mistakes and I'm the first one to stand up and make the claim that I'm far from perfect. But there are just some mistakes that one should not make. In this case, as I was chasing down the question "Why is the add trandata command not working - Eventual answer is because a privilege is missing from the documentation" I went to look at the competing Oracle GoldenGate works to see if they had anything to say on the topic. Much to my horror, I found both books espousing the notion of granting the DBA role to the GoldenGate administrator account! Holly cow! This is far from the Oracle recommendation and it's just plain bad practice. I had to shake my head after reading that in both books no less.

Back to Don't Believe Everything You Read
Which leads to the another point... about books and web pages.... be careful what you read (especially that Freeman guy, watch out for him). Make sure that you think about what you are doing as you are doing it. Not everyone is the Oracle expert they claim to be, and experts come with varying levels of expertise... I've seen web pages that have listed the "solution" to a specific problem with the Oracle database.... and while the solution stated works it is such a bad practice that the person recommending the change ought to be hung.... Ok, I'm not suggesting lynching be re-introduced as a common practice but maybe we ought to threaten a few people with pitchforks, billy clubs and march on them en-mase. This is where the trusted few really come in and make life better for us all. The Tom Kytes, Jonathan Lewises, Cary Millsaps, and the other recognized names in the Oracle community.

It's also where the Oracle documentation comes in, as well as Oracle support. It's also where YOU come in... Which leads to the last point...

File those SR's!!!
When you run into a problem of find a documentation bug what do you do? Do you find your own workaround and then just move on or do you file an SR on the problem and make sure that Oracle is aware of the issue? Look at how vast the documentation library is and you know the likelihood of incorrect or missing information is quite high. The folks that work on the documentation are amazing and do a great job, but as with any kind of writing mistakes happen... with a product as dynamic as Oracle, things are missed... You are an important part of the improvement cycle, so please, take a moment and file that SR or that Documentation bug and make life for all of us a little better.