Look here! It' can't be...!!
Now I KNOW something is wrong with the world!!
Saturday, January 28, 2012
Friday, January 27, 2012
Engineered Systems - Complexity vs. Simplicity...
Oracle started the Engineered Systems decade (my word!) with the introduction of Exadata. Now we have Exalogic and other machines that provide this engineered system concept that I generically like to call Exa* (Exa-Splat). A lot has been touted with respect to the feature sets of these systems, and I've seen enough POV's now (both first-hand and word of mouth) that I can tell you that the performance improvements are real and significant.
However, I think that the story of Engineered system is about much more than being able to take a query that ran before in 24 hours and now it runs in 3 minutes. Sure, that's great and very important, but there is a strategic reason for Engineered systems and I'm not sure that is getting as much play as it should, because I think it's important.
Does this sound like you? Your environment is this collection of loosely coupled systems. You have these great, powerful database servers but when you look at CPU it's sitting at some number like 20 percent. You have servers all over the place. Your behind on your patching. Your constantly standing up new systems, and all the related infrastructure (network, disk, etc) and it just takes time. Your time to provision has the customers complaining. Your spending all your time reacting to problems, to configuring new environments, to wondering why this switch does not work with this server. You spend a lot of time wondering how to integrate various pieces and which technologies are best and which are certified. If this sounds like you, I call you tactical man. You are tactical in your thinking. Your poor customers really don't have the ability to derive knowledge from you because you are busy standing up systems for them. They are building database designs that are amazingly awful, and you are unable to help them because you have to work on the next fire, the next problem.
Is this you:
(phone rings)
You: Hello
Fred: Hey this is Fred. We need help with a database design. What's this normalization thing?
You: Sorry Fred, I'm working on installing four copies of Linux right now, can't help.
Fred: Hey, I understand, you guys are over worked down there. We will just use Hibernate to generate the schema, no problem.
You: No... wai...
(click on the phone)...
Are you tactical man? I wrote some time ago about the holistic DBA and really... becoming the holistic DBA is all about transitioning from Tactical Man to Strategic Man. The truth is that engineered systems can help you in this transition. How you ask... First, look at this handy dandy graphic I whipped up:
This image is kind of an exercise in simplicity (and my limited graphics design abilities) but I think it makes a point. As we move from higher complexity to simplicity, we move from being tactical (reactive) in our work to more strategic and proactive. Also, look at the graphic... in moving in this direction we reduce the number of people required and we reduce the costs as well.
Engineered systems is part of this drive towards simplicity. With an engineered system, you let the vendor do the painstaking work of finding the right components, certifying them, and making them all work together like a well oiled machine. With Engineered systems we get the benefit of scale.... If one problem surfaces on a given system, because the system are all similarly engineered we can immediately apply the solution to the problem across the various enterprises running that engineered system. No more wondering about this or that combination of hardware, we know (more properly the vendor knows) and the vendor take responsibility for providing that remediation across the platforms that are deployed.
Other benefits include the reduction of the proliferation of systems and hardware, reducing the overall footprint that has to be managed. This reduces costs and allows you to again move up towards the strategic part of the graph. There are a number of benefits with respect to the implementation of an engineered solution, be it Exadata or even the Oracle Database Appliance. We should not focus on just one part of the equation (performance) when asking ourselves, what do we do to improve productivity and become more visionary?
As a result... the DBA, the network engineer, the storage administrator, the Unix administrator, are all free to pursue tasks further up the scale, moving in the direction of strategic planning, proactive approaches to business problems and helping the customer do it right the first time. In being visionary about the systems we deploy we can improve our ability to react to strategic needs of the enterprise.
I know... this might sound like a sales pitch for Exa* products.... and I do work for Oracle, but everything I've said here is part of my experience, past and present. Tactical man is alive and the costs of keeping him in business are significant. Strategic man needs to be our goal, and with Strategic man comes a host of benefits including lowered costs and a better Enterprise. Engineered systems can help you migrate to becoming Strategic man...
Sure... really.... we all just love installing Linux and configuring Clusters... but is that really best for the Enterprise? I think not.
However, I think that the story of Engineered system is about much more than being able to take a query that ran before in 24 hours and now it runs in 3 minutes. Sure, that's great and very important, but there is a strategic reason for Engineered systems and I'm not sure that is getting as much play as it should, because I think it's important.
Does this sound like you? Your environment is this collection of loosely coupled systems. You have these great, powerful database servers but when you look at CPU it's sitting at some number like 20 percent. You have servers all over the place. Your behind on your patching. Your constantly standing up new systems, and all the related infrastructure (network, disk, etc) and it just takes time. Your time to provision has the customers complaining. Your spending all your time reacting to problems, to configuring new environments, to wondering why this switch does not work with this server. You spend a lot of time wondering how to integrate various pieces and which technologies are best and which are certified. If this sounds like you, I call you tactical man. You are tactical in your thinking. Your poor customers really don't have the ability to derive knowledge from you because you are busy standing up systems for them. They are building database designs that are amazingly awful, and you are unable to help them because you have to work on the next fire, the next problem.
Is this you:
(phone rings)
You: Hello
Fred: Hey this is Fred. We need help with a database design. What's this normalization thing?
You: Sorry Fred, I'm working on installing four copies of Linux right now, can't help.
Fred: Hey, I understand, you guys are over worked down there. We will just use Hibernate to generate the schema, no problem.
You: No... wai...
(click on the phone)...
Are you tactical man? I wrote some time ago about the holistic DBA and really... becoming the holistic DBA is all about transitioning from Tactical Man to Strategic Man. The truth is that engineered systems can help you in this transition. How you ask... First, look at this handy dandy graphic I whipped up:
This image is kind of an exercise in simplicity (and my limited graphics design abilities) but I think it makes a point. As we move from higher complexity to simplicity, we move from being tactical (reactive) in our work to more strategic and proactive. Also, look at the graphic... in moving in this direction we reduce the number of people required and we reduce the costs as well.
Engineered systems is part of this drive towards simplicity. With an engineered system, you let the vendor do the painstaking work of finding the right components, certifying them, and making them all work together like a well oiled machine. With Engineered systems we get the benefit of scale.... If one problem surfaces on a given system, because the system are all similarly engineered we can immediately apply the solution to the problem across the various enterprises running that engineered system. No more wondering about this or that combination of hardware, we know (more properly the vendor knows) and the vendor take responsibility for providing that remediation across the platforms that are deployed.
Other benefits include the reduction of the proliferation of systems and hardware, reducing the overall footprint that has to be managed. This reduces costs and allows you to again move up towards the strategic part of the graph. There are a number of benefits with respect to the implementation of an engineered solution, be it Exadata or even the Oracle Database Appliance. We should not focus on just one part of the equation (performance) when asking ourselves, what do we do to improve productivity and become more visionary?
As a result... the DBA, the network engineer, the storage administrator, the Unix administrator, are all free to pursue tasks further up the scale, moving in the direction of strategic planning, proactive approaches to business problems and helping the customer do it right the first time. In being visionary about the systems we deploy we can improve our ability to react to strategic needs of the enterprise.
I know... this might sound like a sales pitch for Exa* products.... and I do work for Oracle, but everything I've said here is part of my experience, past and present. Tactical man is alive and the costs of keeping him in business are significant. Strategic man needs to be our goal, and with Strategic man comes a host of benefits including lowered costs and a better Enterprise. Engineered systems can help you migrate to becoming Strategic man...
Sure... really.... we all just love installing Linux and configuring Clusters... but is that really best for the Enterprise? I think not.
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.
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.
Subscribe to:
Posts (Atom)
