My grandpa served in the military, many, many years ago. My father was spared the draft, because I was to be born soon, and he got a bye and didn't goto Vietnam. I don't have uncles or other close relatives that served in the military. I do have a strong desire to support and honor those that have served. I have often reflected on their continued service and protection of our way of life, and felt overwhelmed. I have a neighbor that served in Vietnam, in the motor pool He tells stories of the building next to his, where he slept, being destroyed by enemy fire. The entire building was leveled, while his stood unscathed. We call have stories that we can tell of people we know that served.
Today, as we stayed home from work, and before we went out to play on this vacation day, I logged into the internet and hit Facebook. I saw a couple posts from friends of mine, talking about another friend I went to school with. We were friends. This person, Jason George, was a year younger than me, and we hung in the same circles. After high school, he went on to Westpoint, and more and more education. I only recently reconnected with him over Facebook and we had a few interactions. It was nice to reconnect and see what life had brought him. A while after we reconnected, he was called up to serve again. He spent some time on Facebook trying to get his life here in order, before being sent out to his assignments in Iraq. In April, he arrived in Iraq, and on the 5th of May he arrived in Iraq. While doing foot patrol last week, he, along with 2 other soldiers and 25 Iraqi citizens were killed by a suicide bomber.
This I learned on the morning of Memorial Day. I honor his memory. I will always think of him when I see someone wearing shorts and a sweater. Certain things will always remind me of him, even though we had lost contact these past few years. He bettered himself, and worked hard to gain skills and knowledge. He used this in his professional life as well as his time in the military. He selflessly went over there to assist in the rebuilding of their economy. He hoped to use his skills and knowledge to make it a better place. He put on a soldiers uniform, and tried to make the world a better place. He died doing this. I will always remember him, and especially on this holiday, Memorial Day.
Read his story here.
Monday, May 25, 2009
Friday, May 15, 2009
Releasing Database Objects : Release Management Process
All this week, I have been working on two large releases to our database topology. We have a complicated system, at least when it comes to releasing schema changes. We use a third party replication system that doesnt replicate DDL changes. So, we have to go thru some hoops to push changes out to the systems. And there are multiple systems, some being HOT, others WARM, and so on. We also have multiple environments, Prod, Stage, Integration, and so on.
When our Development group pushes changes out, they are in an Agile mode of developement, and often do not know the actual dates they want to push things out. Often, we'll have slippage of dates, and projects leapfrogging one another. Being on the Service Delivery side of the fence, across the field from the Development group, and apparantly speaking an entirely different dialect of the IT language we all speak, we end up having issues. This week was one of those. A lot of time was spent digging into the release requirements, seeing how this could best be applied to our systems, creating release plans to perform the individual steps, and actually testing these steps in a test environment that mimics our multiple server Production environment. It takes a bit of time to prep the environment, and ensure that the release is ready to be performed, then to actually perform it. Once done, reversing what we just did, and doing it again often occurs.
Needless to say, we are always trying to make the process better, cleaner, smoother, and more effective. The whole idea now is to spend this time now, before a release, and test it over and over, to ensure it succeeds on the actual release time. So far, so good. We are making good progress. The last release, was one of the larger ones we've ever done, and we had no failures or rollbacks.
The biggest problem with these releases and processes? Not the Tech. Not the database. Not the data. Its people dealing with other people. I alluded to it earlier with the IT language quip. But this seems to be the crux of any issues. And I do not stand on the fence saying that those people over there are he fault. Its human interactions and communications that is the problem.
Picking a date and time for a release seems to be an almost impossible task. We currently can pick any day but Friday. Prod releases occur after 6pm, while Stage and all other lower environments can happen any day, any time. And they often do, regardless of the time that was set and agreed upon. Things happen, times slip, often dates slip. Every other scheduled time and date subsequent to the first slippage naturally occurs.
If you have read this far, and was secretly hoping that you'd stumble upon the solution to the above issues, i fear i have to dissapoint you. I do not have them. Each time I think I do, I find that I end up introducing issues that others complain about. Often this is an unforseen side effect to my statements. What I do hope that happens is that if you have read this far, you have applied this story to your systems, and have seen discrepancies between mine and yours and have ways to improve ours. Or, maybe you actually had some ideas of how to alter a release management process and want to share.
So, lets talk, discuss and share.
When our Development group pushes changes out, they are in an Agile mode of developement, and often do not know the actual dates they want to push things out. Often, we'll have slippage of dates, and projects leapfrogging one another. Being on the Service Delivery side of the fence, across the field from the Development group, and apparantly speaking an entirely different dialect of the IT language we all speak, we end up having issues. This week was one of those. A lot of time was spent digging into the release requirements, seeing how this could best be applied to our systems, creating release plans to perform the individual steps, and actually testing these steps in a test environment that mimics our multiple server Production environment. It takes a bit of time to prep the environment, and ensure that the release is ready to be performed, then to actually perform it. Once done, reversing what we just did, and doing it again often occurs.
Needless to say, we are always trying to make the process better, cleaner, smoother, and more effective. The whole idea now is to spend this time now, before a release, and test it over and over, to ensure it succeeds on the actual release time. So far, so good. We are making good progress. The last release, was one of the larger ones we've ever done, and we had no failures or rollbacks.
The biggest problem with these releases and processes? Not the Tech. Not the database. Not the data. Its people dealing with other people. I alluded to it earlier with the IT language quip. But this seems to be the crux of any issues. And I do not stand on the fence saying that those people over there are he fault. Its human interactions and communications that is the problem.
Picking a date and time for a release seems to be an almost impossible task. We currently can pick any day but Friday. Prod releases occur after 6pm, while Stage and all other lower environments can happen any day, any time. And they often do, regardless of the time that was set and agreed upon. Things happen, times slip, often dates slip. Every other scheduled time and date subsequent to the first slippage naturally occurs.
If you have read this far, and was secretly hoping that you'd stumble upon the solution to the above issues, i fear i have to dissapoint you. I do not have them. Each time I think I do, I find that I end up introducing issues that others complain about. Often this is an unforseen side effect to my statements. What I do hope that happens is that if you have read this far, you have applied this story to your systems, and have seen discrepancies between mine and yours and have ways to improve ours. Or, maybe you actually had some ideas of how to alter a release management process and want to share.
So, lets talk, discuss and share.
Thursday, May 07, 2009
Social Networking : It does work
Today, as I looked at my RSS feed, I noticed a new tweep (@AdamMechanic) had a funny comment about twitter. He basically said that he had 'swalloed the twitter-colored pill. With reference to the Matrix, and the blue vs red colored pill scene. So, I thought, what colored pill would it be? The first color that came to my mind was my favorite color of all time. Chartreuse. This color has been a part of my life for as long as I can remember. Many things became painted that color. I would hunt it out and purchase items with it. Then it became a fashionable color, and I started seeing others using it. Many more products were available. This too, like all things, waned and I was left alone again with my favorite color.
Back to twitter, and the comment I made about this being the color of the twitter-colored pill. Back and forth a couple comments flew between me and he about this color, and i learned something new. Apparently, Chartreuse is a color halfway between yellow and green that was named because of its resemblance to the green color of one of the French liqueurs called green chartreuse, introduced in 1764. 1764? This, my favorite color for 20 plus years, a color I had tried to learn about and incorporate into my life, has been around that long and was named after a liqueur? I had no idea. I learned something new. I was amazed.
So, even this has nothing to do with SQL, or may career, it does have to do with the power of talking to people, and being open to learning new things. This technique has been applied to my career and SQL in specific. These are the reasons I blog and joined twitter. But be careful. You must do more than just your career and intended goal of twitter communication to make it work. Expand your communication with others, talk about all kinds of things. Not all the time, but often. Form that ever so slight connection with another human on a level that they can share something with you, and vice-a-versa. Repeat the process with this person and many others.
Then, someday, you tool will have in your toolbox the powerful tool that twitter and social networking can be.
As a side note, later that same morning, I had a simple question that was not SQL related. I posed it on twitter, and got 8 responses 6 people withing 15 minutes. Its like a room full of experts that I can stand in front of and ask a question. Some will respond. Others may not. But you will find that when its your turn to the in the audience, and you can answer, and you do, the answers you will soon need will flow your direction when the tables are turned.
So, join in to the conversation. Speak up. Answer questions. Ask questions. Get involved and tell your tales of how your container of knowledge has increased by your interacting with others.
Back to twitter, and the comment I made about this being the color of the twitter-colored pill. Back and forth a couple comments flew between me and he about this color, and i learned something new. Apparently, Chartreuse is a color halfway between yellow and green that was named because of its resemblance to the green color of one of the French liqueurs called green chartreuse, introduced in 1764. 1764? This, my favorite color for 20 plus years, a color I had tried to learn about and incorporate into my life, has been around that long and was named after a liqueur? I had no idea. I learned something new. I was amazed.
So, even this has nothing to do with SQL, or may career, it does have to do with the power of talking to people, and being open to learning new things. This technique has been applied to my career and SQL in specific. These are the reasons I blog and joined twitter. But be careful. You must do more than just your career and intended goal of twitter communication to make it work. Expand your communication with others, talk about all kinds of things. Not all the time, but often. Form that ever so slight connection with another human on a level that they can share something with you, and vice-a-versa. Repeat the process with this person and many others.
Then, someday, you tool will have in your toolbox the powerful tool that twitter and social networking can be.
As a side note, later that same morning, I had a simple question that was not SQL related. I posed it on twitter, and got 8 responses 6 people withing 15 minutes. Its like a room full of experts that I can stand in front of and ask a question. Some will respond. Others may not. But you will find that when its your turn to the in the audience, and you can answer, and you do, the answers you will soon need will flow your direction when the tables are turned.
So, join in to the conversation. Speak up. Answer questions. Ask questions. Get involved and tell your tales of how your container of knowledge has increased by your interacting with others.
Wednesday, May 06, 2009
GoldenGate replication issues - No More?
Before today, we have not had good luck releasing schema changes to our environment without affecting our GoldenGate replication topology adversely. All ill effects have been surmountable, but stressful, nonetheless. We have a Hot, Warm and DR set of servers that has GoldenGate sending the data from Hot to Warm and Hot to DR. Most of the data is replicated in this fashion, and its fast. We have very little latency, compared to Native Replication we have used in the past.
But doing a release has always been a scary proposition. We would turn things back on, only to have massive errors, and time spent fixing the errors. We have tested and tested and performed more tests to ensure that we have a plan of attack that will succeed.
Today was the day! It all paid off!! We now have a process that allows us to block a table, perform a schema change to it, and through appropriate steps, stop and restart replication where needed. Many steps are needed to perform this, and in this case, it was a two man job to perform the release. The bulk was done in about 14 minutes, with us taking our time, being cautious, and validating our changes. The rest of the release proceeded as a simple release should, and went off without a hitch.
This is a happy day. We have a successful release plan to update schema on live tables, being replicated with GoldenGate replication, without bring it down upon our heads. Yeah.
But doing a release has always been a scary proposition. We would turn things back on, only to have massive errors, and time spent fixing the errors. We have tested and tested and performed more tests to ensure that we have a plan of attack that will succeed.
Today was the day! It all paid off!! We now have a process that allows us to block a table, perform a schema change to it, and through appropriate steps, stop and restart replication where needed. Many steps are needed to perform this, and in this case, it was a two man job to perform the release. The bulk was done in about 14 minutes, with us taking our time, being cautious, and validating our changes. The rest of the release proceeded as a simple release should, and went off without a hitch.
This is a happy day. We have a successful release plan to update schema on live tables, being replicated with GoldenGate replication, without bring it down upon our heads. Yeah.
Subscribe to:
Posts (Atom)
