I'm in LA right now, working on a gig (do we call it a "gig" at Oracle...? Guess I better check with legal on that one).
I'm on the 25th floor of my room.... watching the sun go down and the city lights come on... I look out in the distance and I wonder about all the people out there. I wonder what they are doing... some are still working, some have just gotten home for dinner, some are putting their kids to bed. Some are crying over a lost loved one tonight, others joyful over the birth of a child. Some are lonely, some are getting it on like wild. Some are just sitting and watching TV, and some are working out, sweating to the oldies.
Some, like me, are just sitting out and watching the sea of humanity and wondering what will come next. Dwelling on what was, what could have been and what could be. Life, passing by, one tick after another, and yet with the loudness of society it is still so quiet, so still, so lonely sometimes, isn't it?
And I look up, at the few stars that I can see from here, and I wonder if there are others like us out there. Do they feel, do they hurt, to they cry tears and feel joy? Do they suffer or do they have powers we don't even begin to understand. I wonder if I was born before my time, for I so wish to travel those vast distances and see all the wonders of the universe. I want to see other planets, other species of life.... I want to see all those things.
Also as I look out, I miss those who are gone. My mother, taken from me.... my family all growing up and moving about... getting married and some living far away from me. Missing and lonely, traveling about but not feeling complete.
I still live with my depression you see.... I still find it my silent partner, walking with me, whispering to me songs of lonesomeness, songs of longing, songs of frustration and wistfulness. A desire to magically transform all at the sound of my voice, so that all will be right with the world. So that all will be in it's proper place, in it's proper prospective.
And the sun goes down, and night comes. The lovers love or they quarrel. The widow sits alone, silent waiting to return to her loved one. The children sleep dreaming of mickey mouse, Donald duck or a cat named Clifford. Men sit in prison, guilty and innocent. Their wives and children thinking of them, loving them. It is a world that goes on and on, lives in the millions and I sit here, from the 25th story and silently observe them in my mind, and watch the lights as they twinkle.
Good night America.....
Monday, April 25, 2011
Sunday, April 24, 2011
The changing world of the DBA (Part 2) - DBA 3.0
My first post received some great comments and so I want to continue with the theme of the changing world of the DBA. Back some years ago there was this Collaborate (or Open World I can't remember now) session that was DBA 1.0 vs. DBA 2.0. In this session, our gallant 1.0 DBA stepped up and used scripts, and the equally gallant DBA 2.0 used OEM to manage the database. This was in an effort to prove the virtues of DBA 2.0, using the automated tools that Oracle makes available and so on. I thought it was a great session and I think that it might not quite have proved the case for DBA 2.0. DBA 1.0 was still pretty in the thick of things with his scripts, but I will say that I like the GUI's for lots of things too.
I submit though that we need to move beyond the DBA 1.0 and 2.0 world, and become DBA 3.0.... Maybe we should have been DBA 3.0 in the first place and we just didn't realize it.
In one comment from Michael "Misha" Rosenblum there was a suggestion of a "development DBA". He sugested the following attributes for a development DBA:
[he would be] a senior specialist that would have enough knowledge of database architecture "to be dangerous", but mainly be involved in two key areas:
working on impact analysis/advanced research for the senior management.
[he would be a]bridge between all groups (educating developers about new features, translating to "real-DBA" all needs of developers etc, making sure that architects are staying in this Universe etc).
This would be a good start I think, but I think that DBA 3.0 goes deeper than this. Some organizations have development DBA's, some have architects, the job of database and data design can be pretty watered down at times. However, it seems to me that in most (there are always exceptions) places I've seen, be it a development DBA, a regular DBA, an DBA architect, what have you, we are often late to the ball.
We often show up at the door after the party has started, the decorations are up, the music has been selected and the guests have arrived. We are late to the party to find that the guests are all under age, the drinks are all alcoholic, the party favors have not been delivered nor ordered, the seats are missing pieces to make the sit up properly, and we don't have enough budget money for speakers because someone forgot that when you order a stereo for the DJ, you might just want speakers and the cables for those speakers (or just as likely the speakers were ordered with the cables that are incompatible).
The point is, that we were not involved at the beginning. Why was this? We probably had heard somewhere about the party that was coming, heck we even got an invitation to it at some point. We knew that our skills would probably come to bear at the party since we know a thing or two about planning parties. So why did we not get involved.
There may well be a lot of reasons for that. It could be that party planning is just one of our many responsibilities. It could be that we have many parties going on, in different stages and at different locations. It could be that we are just sitting back at our station, watching the monitors, making sure that people are doing the things they are supposed to be doing. We are looking at the things we know have to be going on, but not really thinking about the things that are not going on (like the ordering of the alcohol).
Perhaps management has turned us into mere security guards, watching these monitors because that is what management thinks we do. Have we told them differently? Have we tried to tell management that we need to be pro-active and not reactive. Maybe we are comfortable sitting and watching those monitors, is that possible? There sure it a lot less risk doing that.
Still, time after time we see the disasters happen. Party after party just does not work right, success is not repeatable. We see all the reasons why, but what can we do?
The same is true of many (not all) DBA's. At time, it's the DBA who is at fault. Some are comfortable sitting in their little space, controlling their little domain, keeping their heads down, being the hero when they tune every slow piece of SQL that comes across their desk. All hail the DBA who can tune anything. Really though, I submit that if SQL code continues to need tuned by the DBA then there is only one person at fault for that, the DBA.
There are the DBA's that enjoy a good laugh too. They joke when the hardware is not ordered on time, when the wrong components are ordered or when things are not configured properly. These DBA's live on the failures of others, making themselves look so much the better. But really, are we? As one commenter responded in my previous post:
"In my opinion a DBA is a guardian of data."
And I could not agree more and yet, do we really do all the things needed to guard that data if we are just sitting in our little cubicles and watching things happen. Waiting for parts to be ordered, delivered and put together.
Are we guarding that data if we are not there at the beginning, articulating to management what our role really should be. Are we there making sure we understand what hardware and OS that others are deciding we should use is the right choice? Are we there, fighting the good fights (loosing once in a while) or are we cowards, or so politically correct that we can't stand up and say, this isn't the right choice.
Are we on the front end of modeling, or are we allowing developers to start the modeling before we ever get involved. Are we cowering to demands from others that we allow tools to model the database for us, or that we don't need to model in 3NF because of this reason, or that reason?
If it because we really don't understand and can't articulate the reasons to model in 3NF? Is it because we can't articulate in a language that business and development understands the need for the use of best practices and that, 3NF performs just fine, thank you very much, if you think in terms of groups/sets rather than procedural thinking.
The point is, if we don't understand what we are doing, how can we hope to help others to understand how important these things are? If we understand but we can't articulate to others how important these things are, how can we hope to ever become DBA 3.0?
I submit that we must become DBA 3.0, and beyond. We must learn to change, we must learn to communicate, we must learn how databases work, why backups are important, why DR is important and learn to communicate that. We need to learn how to translate things like outages into dollars, which is the language that the business and management understands. I assure you a manager will understand "The cost of a two hour outage to this company is 3.5 Million dollars and that cost doubles every two hours." rather than "We need a DR plan, there are terrorists out there!"
Ok..... my flight is landing.... more later. Your thoughts are quite welcome!
I submit though that we need to move beyond the DBA 1.0 and 2.0 world, and become DBA 3.0.... Maybe we should have been DBA 3.0 in the first place and we just didn't realize it.
In one comment from Michael "Misha" Rosenblum there was a suggestion of a "development DBA". He sugested the following attributes for a development DBA:
[he would be] a senior specialist that would have enough knowledge of database architecture "to be dangerous", but mainly be involved in two key areas:
working on impact analysis/advanced research for the senior management.
[he would be a]bridge between all groups (educating developers about new features, translating to "real-DBA" all needs of developers etc, making sure that architects are staying in this Universe etc).
This would be a good start I think, but I think that DBA 3.0 goes deeper than this. Some organizations have development DBA's, some have architects, the job of database and data design can be pretty watered down at times. However, it seems to me that in most (there are always exceptions) places I've seen, be it a development DBA, a regular DBA, an DBA architect, what have you, we are often late to the ball.
We often show up at the door after the party has started, the decorations are up, the music has been selected and the guests have arrived. We are late to the party to find that the guests are all under age, the drinks are all alcoholic, the party favors have not been delivered nor ordered, the seats are missing pieces to make the sit up properly, and we don't have enough budget money for speakers because someone forgot that when you order a stereo for the DJ, you might just want speakers and the cables for those speakers (or just as likely the speakers were ordered with the cables that are incompatible).
The point is, that we were not involved at the beginning. Why was this? We probably had heard somewhere about the party that was coming, heck we even got an invitation to it at some point. We knew that our skills would probably come to bear at the party since we know a thing or two about planning parties. So why did we not get involved.
There may well be a lot of reasons for that. It could be that party planning is just one of our many responsibilities. It could be that we have many parties going on, in different stages and at different locations. It could be that we are just sitting back at our station, watching the monitors, making sure that people are doing the things they are supposed to be doing. We are looking at the things we know have to be going on, but not really thinking about the things that are not going on (like the ordering of the alcohol).
Perhaps management has turned us into mere security guards, watching these monitors because that is what management thinks we do. Have we told them differently? Have we tried to tell management that we need to be pro-active and not reactive. Maybe we are comfortable sitting and watching those monitors, is that possible? There sure it a lot less risk doing that.
Still, time after time we see the disasters happen. Party after party just does not work right, success is not repeatable. We see all the reasons why, but what can we do?
The same is true of many (not all) DBA's. At time, it's the DBA who is at fault. Some are comfortable sitting in their little space, controlling their little domain, keeping their heads down, being the hero when they tune every slow piece of SQL that comes across their desk. All hail the DBA who can tune anything. Really though, I submit that if SQL code continues to need tuned by the DBA then there is only one person at fault for that, the DBA.
There are the DBA's that enjoy a good laugh too. They joke when the hardware is not ordered on time, when the wrong components are ordered or when things are not configured properly. These DBA's live on the failures of others, making themselves look so much the better. But really, are we? As one commenter responded in my previous post:
"In my opinion a DBA is a guardian of data."
And I could not agree more and yet, do we really do all the things needed to guard that data if we are just sitting in our little cubicles and watching things happen. Waiting for parts to be ordered, delivered and put together.
Are we guarding that data if we are not there at the beginning, articulating to management what our role really should be. Are we there making sure we understand what hardware and OS that others are deciding we should use is the right choice? Are we there, fighting the good fights (loosing once in a while) or are we cowards, or so politically correct that we can't stand up and say, this isn't the right choice.
Are we on the front end of modeling, or are we allowing developers to start the modeling before we ever get involved. Are we cowering to demands from others that we allow tools to model the database for us, or that we don't need to model in 3NF because of this reason, or that reason?
If it because we really don't understand and can't articulate the reasons to model in 3NF? Is it because we can't articulate in a language that business and development understands the need for the use of best practices and that, 3NF performs just fine, thank you very much, if you think in terms of groups/sets rather than procedural thinking.
The point is, if we don't understand what we are doing, how can we hope to help others to understand how important these things are? If we understand but we can't articulate to others how important these things are, how can we hope to ever become DBA 3.0?
I submit that we must become DBA 3.0, and beyond. We must learn to change, we must learn to communicate, we must learn how databases work, why backups are important, why DR is important and learn to communicate that. We need to learn how to translate things like outages into dollars, which is the language that the business and management understands. I assure you a manager will understand "The cost of a two hour outage to this company is 3.5 Million dollars and that cost doubles every two hours." rather than "We need a DR plan, there are terrorists out there!"
Ok..... my flight is landing.... more later. Your thoughts are quite welcome!
Monday, April 18, 2011
The changing world of the DBA...
It seems that I'm finding myself gravitating towards two non-technical discussions related to the world of the DBA these days. The first is the nature of the changing world of the DBA. The second has to do with support, using support efficiently and getting what you want from support.
In this Blog post I think I'll address some of my thoughts on the changing world of the DBA. I've talked about this at several presentations and have gotten good feedback on some of my comments. In fact I'm thinking of putting together a presentation on this topic as a whole.
The bottom line is that our world (as a DBA) is changing. It used to be that we were all kept busy with the day-to-day drudgery of managing our databases. We were busy trying to keep the thing up and and running, responding reactivity to user requests and imminent fires and really didn't have time for much of anything else, or perhaps we didn't make time for anything else. I think many of us liked working in reactive mode, liked being the hero in spite of the 2am calls. We liked being the DBA, who was talked about in hushed reverent silence in the halls because of our awesome skills and how we saved the day. This kind of thing appeals to our ego, and is a very positive reinforcement behavioral loop. We were DBA's, Database Administrators.
I'd like to propose a new definition of the acronym DBA. I'd like to change it to one of the following:
Database Advocate
Database Articulater (which I don't think is a word, but I'm not above making words up if they serve my purpose).
The point is that DBA's (administrators) can no longer afford to do our jobs in a "Business as usual" type of mentality. If so you will find yourself becoming a dying breed. We can no longer spend our time huddled in our cubes (or at home!) looking at tablespace available space, looking for disk space, helping users tune SQL statements, creating accounts, unlocking accounts, and so on. All of these things are time consuming tasks that are easy to automate.
Why are we spending our time tuning SQL statements? Why are we spending out time fighting COTS applications that don't work well? I propose that the reasons we are doing these things is because we are not doing the job we should be doing, and that we have not communicated effectively to management and the business what our jobs really should be and what we should be doing to really provide the best value to the enterprise.
I'll have some more thoughts about this in my next post...
Robert
In this Blog post I think I'll address some of my thoughts on the changing world of the DBA. I've talked about this at several presentations and have gotten good feedback on some of my comments. In fact I'm thinking of putting together a presentation on this topic as a whole.
The bottom line is that our world (as a DBA) is changing. It used to be that we were all kept busy with the day-to-day drudgery of managing our databases. We were busy trying to keep the thing up and and running, responding reactivity to user requests and imminent fires and really didn't have time for much of anything else, or perhaps we didn't make time for anything else. I think many of us liked working in reactive mode, liked being the hero in spite of the 2am calls. We liked being the DBA, who was talked about in hushed reverent silence in the halls because of our awesome skills and how we saved the day. This kind of thing appeals to our ego, and is a very positive reinforcement behavioral loop. We were DBA's, Database Administrators.
I'd like to propose a new definition of the acronym DBA. I'd like to change it to one of the following:
Database Advocate
Database Articulater (which I don't think is a word, but I'm not above making words up if they serve my purpose).
The point is that DBA's (administrators) can no longer afford to do our jobs in a "Business as usual" type of mentality. If so you will find yourself becoming a dying breed. We can no longer spend our time huddled in our cubes (or at home!) looking at tablespace available space, looking for disk space, helping users tune SQL statements, creating accounts, unlocking accounts, and so on. All of these things are time consuming tasks that are easy to automate.
Why are we spending our time tuning SQL statements? Why are we spending out time fighting COTS applications that don't work well? I propose that the reasons we are doing these things is because we are not doing the job we should be doing, and that we have not communicated effectively to management and the business what our jobs really should be and what we should be doing to really provide the best value to the enterprise.
I'll have some more thoughts about this in my next post...
Robert
Wednesday, April 06, 2011
Working with Oracle Support....
My new itch of late is Oracle support and trying to help customers work effectively with Oracle support. I hear a lot of people complain about support. Sometimes the complaints are valid but just as often I find that people don't understand how to work the support organization. As a result of these observations I thought I'd share a few tidbits over the next few weeks for you to review and comment on. Note, I don't work for the support organization and I'm well aware that people have had great experiences and not so great experiences with support. I find though, in general, the more you know how to work with the support organization, the better the results you will get.
With that, today I'd suggest that you log into Metalink and review Oracle Note 166650.1 for additional information about the My Oracle Support Portal and Working Effectively with Oracle Support. This note will give you a good over view of working with the Oracle support organization.
Also Oracle is starting a series of "Advisor Webcasts". The webcasts will cover a number of topics over time to help you leverage Oracle support and several key features found in the my Oracle Support portal. The first of the webcasts include Certification searches for database product certifications and the ORA-600/7445 troubleshooting tool. Please take a look at note 1300014.1 for more information on these and future webcast events.
I hope to get my blog rolling again .... it will have Oracle and non-Oracle related content, and I hope to update it much more frequently.
For those of you following my depression... it's much better now... I am leveled on meds and feel better.
With that, today I'd suggest that you log into Metalink and review Oracle Note 166650.1 for additional information about the My Oracle Support Portal and Working Effectively with Oracle Support. This note will give you a good over view of working with the Oracle support organization.
Also Oracle is starting a series of "Advisor Webcasts". The webcasts will cover a number of topics over time to help you leverage Oracle support and several key features found in the my Oracle Support portal. The first of the webcasts include Certification searches for database product certifications and the ORA-600/7445 troubleshooting tool. Please take a look at note 1300014.1 for more information on these and future webcast events.
I hope to get my blog rolling again .... it will have Oracle and non-Oracle related content, and I hope to update it much more frequently.
For those of you following my depression... it's much better now... I am leveled on meds and feel better.
Subscribe to:
Posts (Atom)
