Sunday, July 6, 2008
Process
I read The Daily WTF, well, daily. On Thursday last week, there was a good one on process. Essentially, the entire process had to be followed when an error occurred at boot. F1 would have solved the problem immediately...
My first job I never really got to put anything into production, so I wasn't real familiar with it. My second job, I was the lone ranger, so I did everything myself (though I did not do development in production). My last job however, was full of "The Process."
Rightfully so, especially in a large environment (i.e. more than 1 developer), though I think it was a bit overdone. And up until one of my failed deployments, the deployment itself was done through the Change Request (CR). What I mean by that, is that the code was attached to the CR itself. Since I attached a newer version, which had not been QA'd, well, you get the picture. We finally moved to a system whereby the DBAs actually deployed from our source control system...thankfully.
Now I'm in an environment that's a mix between the last job and the second to last. Everything is QA'd, but there isn't this whole process surrounding deployments...yet. Fortunately we're small enough to deal with it.
What's the point? I'm not sure.
Perhaps it's that I've learned more what not to do from The Daily WTF...
My first job I never really got to put anything into production, so I wasn't real familiar with it. My second job, I was the lone ranger, so I did everything myself (though I did not do development in production). My last job however, was full of "The Process."
Rightfully so, especially in a large environment (i.e. more than 1 developer), though I think it was a bit overdone. And up until one of my failed deployments, the deployment itself was done through the Change Request (CR). What I mean by that, is that the code was attached to the CR itself. Since I attached a newer version, which had not been QA'd, well, you get the picture. We finally moved to a system whereby the DBAs actually deployed from our source control system...thankfully.
Now I'm in an environment that's a mix between the last job and the second to last. Everything is QA'd, but there isn't this whole process surrounding deployments...yet. Fortunately we're small enough to deal with it.
What's the point? I'm not sure.
Perhaps it's that I've learned more what not to do from The Daily WTF...
Labels: development, process, work
¶ 7/06/2008 11:18:00 PM 0 Comments Links to this post
Thursday, June 26, 2008
Corporate Life III
See Part I and Part II.
In Part I of Corporate Life, I said:
prodlife then mentioned that I hadn't experienced layoffs.
Four months later I did, on May 22, WellCare laid off 208 employees. I blogged it. I was fired.
I'm up to five corporate experiences.
I'm still missing the merger/acquisition and the IPO. Anything I'm missing? ¶ 6/26/2008 11:54:00 PM 0 Comments Links to this post
In Part I of Corporate Life, I said:
It feels like I've experienced about every event I could have imagined:
1. In January of 2007, a new CIO/SVP was hired and promptly restructured (replaced the VPs) the IT department.
2. In October of 2007, we had a nifty FBI raid.
3. January of 2008, we appear to be losing our CEO, CFO and General Counsel.
prodlife then mentioned that I hadn't experienced layoffs.
Four months later I did, on May 22, WellCare laid off 208 employees. I blogged it. I was fired.
I'm up to five corporate experiences.
I'm still missing the merger/acquisition and the IPO. Anything I'm missing? ¶ 6/26/2008 11:54:00 PM 0 Comments Links to this post
Wednesday, June 18, 2008
Long Live the Revolution!
Revolution Money that is...
I'm no longer afraid to at least say that, though if you had checked out my LinkedIn profile, you would have seen it.
Revolution Money is a startup company described as "PayPal meets MasterCard" without the fees. Among the board members are:
So far I am extremely happy, though I don't really know how to deal with the distress that is no longer there. I suppose it will wane with time...
Everyone I work with seems to be amongst the best and brightest which is pretty cool. My view (pictures coming soon) is pretty awesome. Relaxed environment (think casual Friday every day). The CEO brings his dog into work...
I should have the opportunity to learn quite a bit here.
I'm no longer afraid to at least say that, though if you had checked out my LinkedIn profile, you would have seen it.
Revolution Money is a startup company described as "PayPal meets MasterCard" without the fees. Among the board members are:
- Steve Case, founder of AOL
- Ted Leonsis (here and here), among other things, he is the current owner of the Washington Capitols
- Larry Summers, former Secretary of the Treasury
So far I am extremely happy, though I don't really know how to deal with the distress that is no longer there. I suppose it will wane with time...
Everyone I work with seems to be amongst the best and brightest which is pretty cool. My view (pictures coming soon) is pretty awesome. Relaxed environment (think casual Friday every day). The CEO brings his dog into work...
I should have the opportunity to learn quite a bit here.
Labels: work
¶ 6/18/2008 08:21:00 PM 2 Comments Links to this post
Friday, May 30, 2008
I've Got a New Job!
Woohoo!
(Internal Dialog)
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
*This post was approved by my wife. ;) ¶ 5/30/2008 09:23:00 AM 16 Comments Links to this post
(Internal Dialog)
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
I will talk to them before writing anything about them.
*This post was approved by my wife. ;) ¶ 5/30/2008 09:23:00 AM 16 Comments Links to this post
Thursday, May 29, 2008
Blogging Safely Part II
Man, I just have too much time on my hands.
I've debated whether I should write about the specifics of my termination. Yes. No. Yes. No. Alright, no.
After counsel from a few fellow bloggers (how cool is that? A built in support group!), I've decided against it. If I were independently wealthy (read: not dependent on a salary), I might.
I am also trying to take the high-road, trying to have some class I guess.
The more I sit around the worse I feel about it too. It is/was a humbling experience.
Yes, I was ready (and looking) to leave. But to be walked out of the building is not fun (though many thought I was just playing another prank). I wish it had not happened that way.
I do have my own opinions and I will voice them, but when a decision is made, I usually just shut my mouth and either live with it or look for a new job (if I totally disagree). Many people view this as arrogance I believe. That I am not open to new ideas. That is most definitely not the case.
(can you say rambling?)
So, if you blog and haven't read my previous post on Blogging Safely, do it now. Something good must come out of this.
Discuss blogging with your employer. See if they have guidelines on blogging. If not, err on the side of caution.
Thanks to everyone for your support. It reminds me of the support I received last year at this time when my daughter fell ill. Now I have a virtual family!
I've debated whether I should write about the specifics of my termination. Yes. No. Yes. No. Alright, no.
After counsel from a few fellow bloggers (how cool is that? A built in support group!), I've decided against it. If I were independently wealthy (read: not dependent on a salary), I might.
I am also trying to take the high-road, trying to have some class I guess.
The more I sit around the worse I feel about it too. It is/was a humbling experience.
Yes, I was ready (and looking) to leave. But to be walked out of the building is not fun (though many thought I was just playing another prank). I wish it had not happened that way.
I do have my own opinions and I will voice them, but when a decision is made, I usually just shut my mouth and either live with it or look for a new job (if I totally disagree). Many people view this as arrogance I believe. That I am not open to new ideas. That is most definitely not the case.
(can you say rambling?)
So, if you blog and haven't read my previous post on Blogging Safely, do it now. Something good must come out of this.
Discuss blogging with your employer. See if they have guidelines on blogging. If not, err on the side of caution.
Thanks to everyone for your support. It reminds me of the support I received last year at this time when my daughter fell ill. Now I have a virtual family!
Labels: blogging, humility, work
¶ 5/29/2008 11:37:00 PM 3 Comments Links to this post
Wednesday, May 28, 2008
Blogging Safely
Jake from AppsLab left a link in the comments to my previous post, Lessons Learned. The link was to an article about Mark Jen, who was fired from Google after 11 days for blogging.
It got me curious as to what was out there, so below is a list of links that point to either "safe blogging" articles or those that were fired for blogging about their company.
Lessons Learned From Google Blogger Who Got Fired - 5 lessons here. #5 is, "Don't make the same mistake twice."
Of Blogging and Unemployment - a former Microsoft employee gets the sack.
Delta employee fired over blog sues company
Fired simply for having a blog
Beware if your blog is related to work
Have a blog, lose your job?
Avoid getting fired for blogging
Warning: Your clever little blog could get you fired
How to Blog Safely (About Work or Anything Else)
Or you can just google it.
Back to lessons learned, I'll speak with management or HR at my next company to see if they have guidelines. If not, I'll err on the cautious side and not mention anything.
It got me curious as to what was out there, so below is a list of links that point to either "safe blogging" articles or those that were fired for blogging about their company.
Lessons Learned From Google Blogger Who Got Fired - 5 lessons here. #5 is, "Don't make the same mistake twice."
Of Blogging and Unemployment - a former Microsoft employee gets the sack.
Delta employee fired over blog sues company
Fired simply for having a blog
Beware if your blog is related to work
Have a blog, lose your job?
Avoid getting fired for blogging
Warning: Your clever little blog could get you fired
How to Blog Safely (About Work or Anything Else)
Or you can just google it.
Back to lessons learned, I'll speak with management or HR at my next company to see if they have guidelines. If not, I'll err on the cautious side and not mention anything.
Labels: blogging, humility, work
¶ 5/28/2008 10:03:00 PM 5 Comments Links to this post
Lessons Learned
I was let go yesterday. Many thought that it was another one of my pranks...which was funny. Following are my lessons learned from my time there:
1. Get express written permission about what you can (if anything) and cannot blog about.
2. Not everyone is your friend.
3. Not everyone will like you...just because.
4. Some people will not hesitate to throw you under the bus.
5. Big companies might not be the place for me.
6. Big companies are full of many motivated and talented people.
I learned a great deal in the year and a half. My family and I moved from Gainesville to Tampa and it was the best decision we've made so far.
I was exposed to data warehousing which was a challenge to say the least. To spend a week trying to figure out the best way to move data was an interesting exercise.
I was exposed to big company politics which was fun.
Overall my experience there was positive. I learned a great deal both personally and professionally. I met and hope to retain many good friends and I will miss all of them dearly.
1. Get express written permission about what you can (if anything) and cannot blog about.
2. Not everyone is your friend.
3. Not everyone will like you...just because.
4. Some people will not hesitate to throw you under the bus.
5. Big companies might not be the place for me.
6. Big companies are full of many motivated and talented people.
I learned a great deal in the year and a half. My family and I moved from Gainesville to Tampa and it was the best decision we've made so far.
I was exposed to data warehousing which was a challenge to say the least. To spend a week trying to figure out the best way to move data was an interesting exercise.
I was exposed to big company politics which was fun.
Overall my experience there was positive. I learned a great deal both personally and professionally. I met and hope to retain many good friends and I will miss all of them dearly.
Labels: blogging, discipline, humility, work
¶ 5/28/2008 01:28:00 PM 9 Comments Links to this post
Wednesday, May 14, 2008
Socially Networked Employees Are Better?
Here's one for Jake from AppsLab.
Apparently one person has equated the Social Networking to performance in the [IT] work-place.
I thought it was a pretty good article. I would hope that I am one of the people that others choose to go to, but I'll probably never know.
Apparently one person has equated the Social Networking to performance in the [IT] work-place.
I thought it was a pretty good article. I would hope that I am one of the people that others choose to go to, but I'll probably never know.
Labels: work
¶ 5/14/2008 08:01:00 PM 2 Comments Links to this post
Tuesday, May 6, 2008
Oracle at Home: The Results
Almost 70% of you responded that you do not have Oracle installed at home. That was a bit of a shocker to me.
I figured that it would be the other way around; people who read blogs, Oracle blogs specifically, would be more likely to have Oracle installed at home.
So, why not?
I figured that it would be the other way around; people who read blogs, Oracle blogs specifically, would be more likely to have Oracle installed at home.
So, why not?
Labels: database, home, oracle, work
¶ 5/06/2008 10:39:00 PM 5 Comments Links to this post
Tuesday, April 29, 2008
Validating a Process
I mentioned sometime back that I would be posting the code. I can't post the entire set of code but I can post the relevant parts.
Inbound Remittance Advice files are loaded into our Operational Data Store (ODS). We have absolutely no control over this, it lies with another group. On occasion, those files are double, or even triple, loaded.
To provide the business (and ourselves) with a way to track when files came in and if the entire processed worked as expected (no lost dollars, no lost record counts).
1. Read the files when they first come in (on disk).
2. Query the appropriate tables at certain intervals to verify it matches the file amounts.
3. Load those results into a table and then fail the normal load process if we detect any incongruities.
1. Create a directory object on the Oracle server.
2. Copy inbound files to that directory.
3. Read files from that directory (Java anyone?)
4. Load files into CLOBs (so that I don't have to spend half my day finding the damn things, simple APEX app and I'm good to go).
5. Parse files to find relevant information (Java)
6. Query tables at various stages, blah blah blah.
Since the UTL_FILE doesn't have a function to read the contents of a directory, Java comes into play. I've done it before and I found the code originally on asktom (where else?).
For those of you too lazy (like me) to click the link, here's the important stuff:
I have to use Reader and CharacterStream, getting well beyond my knowledge of Java.
With the help of a fellow Java developer, I was pointed towards StreamTokenizer which works in a similar fashion to StringTokenizer, or so I thought. Apparently StreamTokenizer is one of the lower level classes...so I had to figure out the ASCII values of the character I wanted to split on (a tilde: ~). I think my Java friend was surprised I figured this out...
After I got that as a String, I could then use the StringTokenizer, which I knew.
Could I have split the CLOB using PL/SQL? Yes. Did I want to? Not really. I was already using Java so why not just use the Tokenizer?
The five classes were jarred and loaded into Oracle via the loadjava command. Wrap it all up in PL/SQL and life is easy!
Problem
Inbound Remittance Advice files are loaded into our Operational Data Store (ODS). We have absolutely no control over this, it lies with another group. On occasion, those files are double, or even triple, loaded.
Goal
To provide the business (and ourselves) with a way to track when files came in and if the entire processed worked as expected (no lost dollars, no lost record counts).
What do we do?
1. Read the files when they first come in (on disk).
2. Query the appropriate tables at certain intervals to verify it matches the file amounts.
3. Load those results into a table and then fail the normal load process if we detect any incongruities.
Solution (proposed)
1. Create a directory object on the Oracle server.
2. Copy inbound files to that directory.
3. Read files from that directory (Java anyone?)
4. Load files into CLOBs (so that I don't have to spend half my day finding the damn things, simple APEX app and I'm good to go).
5. Parse files to find relevant information (Java)
6. Query tables at various stages, blah blah blah.
Solution
Since the UTL_FILE doesn't have a function to read the contents of a directory, Java comes into play. I've done it before and I found the code originally on asktom (where else?).
For those of you too lazy (like me) to click the link, here's the important stuff:
snip...Since I'm using Java, I might as well use the StringTokenizer, makes like so much easier. But wait, since I'm reading it as a CLOB (and not a String), what do I do? I tried clob.toString(). Nope, it's just a pointer to the actual CLOB.
File file = new File( path );
list = file.list();
for ( int i = 0; i < list.length; i++ )
{
File indvidualFile = new File( path + list[i] );
if ( indvidualFile.isFile() )
{
element = list[i];
statement.setString( 1, element );
}
}
snip...
I have to use Reader and CharacterStream, getting well beyond my knowledge of Java.
With the help of a fellow Java developer, I was pointed towards StreamTokenizer which works in a similar fashion to StringTokenizer, or so I thought. Apparently StreamTokenizer is one of the lower level classes...so I had to figure out the ASCII values of the character I wanted to split on (a tilde: ~). I think my Java friend was surprised I figured this out...
Fun.
Reader characterStream = clob.getCharacterStream();
StreamTokenizer stream = new StreamTokenizer( characterStream );
stream.resetSyntax();
stream.wordChars( 32, 125 );
stream.parseNumbers();
After I got that as a String, I could then use the StringTokenizer, which I knew.
Could I have split the CLOB using PL/SQL? Yes. Did I want to? Not really. I was already using Java so why not just use the Tokenizer?
The five classes were jarred and loaded into Oracle via the loadjava command. Wrap it all up in PL/SQL and life is easy!
¶ 4/29/2008 07:51:00 PM 0 Comments Links to this post
PROCEDURE get_directory_contents( i_directory IN VARCHAR2 )
AS
LANGUAGE JAVA NAME 'com.hmocompany.dw.LoadFileNames.getFileNames( java.lang.String )';
Monday, April 21, 2008
It's a Matter of Time
I've been thinking a lot lately about my recent failed deployments.
How did I get so sloppy?
I'm not one to make excuses, but I would say there are some mitigating circumstances at least. Time being one of them.
So I got out my trusty calculator (SQL*Plus), and ran the numbers.
From August 26, 2007 through March 30, 2008, I've worked 1802 hours. Of that, 118 were PTO or holiday, which brings the total down to 1784. For perspective, a work year of 8 hours per day comes out to 2080 hours a year.
Cool! Only 86% of my hours in a little over 6 months!
Obviously, this is not a good thing.
Further breaking the numbers down:
DB = Days Between
BD = Business Days
HPD = Hours Per Day
HPDW = Hours Per Day/Week
HPWD = Hours Per Work Day
HPWW = Hours Per Work Week
The scary part is that I am not very diligent about entering my time. It's probably short anywhere between 5 and 10%.
I'm not the only one working these kinds of hours either. I know for a fact there are others.
Do you think this plays a role in my failed deployments?
How did I get so sloppy?
I'm not one to make excuses, but I would say there are some mitigating circumstances at least. Time being one of them.
So I got out my trusty calculator (SQL*Plus), and ran the numbers.
From August 26, 2007 through March 30, 2008, I've worked 1802 hours. Of that, 118 were PTO or holiday, which brings the total down to 1784. For perspective, a work year of 8 hours per day comes out to 2080 hours a year.
VAR HOURS NUMBER;
EXEC :hours := 1784
1 SELECT
2 ROUND( ( :HOURS / 2080 ) * 100, 1 ) per_of_tot_year_hours
3* FROM DUAL
ETL_WRK@ORA10GR2>/
PER_OF_TOT_YEAR_HOURS
---------------------
85.8
Cool! Only 86% of my hours in a little over 6 months!
Obviously, this is not a good thing.
Further breaking the numbers down:
VAR C VARCHAR2(10);
EXEC :C := '26-AUG-07';
SELECT
start_day,
end_day,
days_between db,
SUM( business_days ) bd,
ROUND( ( :hours / days_between ), 1 ) hpd,
ROUND( ( :hours / ( days_between / 7 ) ), 1 ) hpdw,
ROUND( ( :hours / SUM( business_days ) ), 1 ) hpwd,
ROUND( ( :hours / SUM( business_days / 5 ) ), 1 ) hpww
FROM
(
SELECT
start_day,
end_day,
TRUNC( end_day - start_day ) days_between,
start_day + rownum dayof,
( CASE
WHEN TO_CHAR( start_day + rownum, 'D' ) IN ( 2, 3, 4, 5, 6 ) THEN
1
END ) business_days
FROM
dual a,
(
SELECT
TO_DATE( :c, 'DD-MON-YY' ) start_day,
TO_DATE( '30-MAR-08', 'DD-MON-YY' ) end_day
FROM dual
) b
CONNECT BY LEVEL <= TRUNC( end_day - start_day )
)
GROUP BY
start_day,
end_day,
days_between
/
START_DAY END_DAY DB BD HPD HPDW HPWD HPWW
---------- ---------- ------ ------ ------ ------ ------ ------
08/26/2007 03/30/2008 217 155 8.2 57.5 11.5 57.5
DB = Days Between
BD = Business Days
HPD = Hours Per Day
HPDW = Hours Per Day/Week
HPWD = Hours Per Work Day
HPWW = Hours Per Work Week
The scary part is that I am not very diligent about entering my time. It's probably short anywhere between 5 and 10%.
I'm not the only one working these kinds of hours either. I know for a fact there are others.
Do you think this plays a role in my failed deployments?
Labels: discipline, sql, work
¶ 4/21/2008 08:11:00 PM 4 Comments Links to this post
Thursday, April 17, 2008
Failed Deployments: An Index
Since there seem to be so many now, I'm creating this index page to track them. Enjoy!
The Countdown Timer - a brief not on the origin of the countdown timer adorning my site.
Good Day to Worse Day - This is the day that the countdown timer was first started.
DELETEng an entire production table.
Blowing up the Rate Application.
The Countdown Timer - a brief not on the origin of the countdown timer adorning my site.
Good Day to Worse Day - This is the day that the countdown timer was first started.
DELETEng an entire production table.
Blowing up the Rate Application.
Labels: development, failed, humility, work
¶ 4/17/2008 09:01:00 PM 0 Comments Links to this post
Another Failed Deployment...
Just before I went on vacation I (we) deployed an application so that our finance group could maintain their own rates.
We were doing between 5 and 8 critical change requests a month, unacceptable. I fought months ago to bring the rates into the data warehouse so that we could own them and eventually build this application (in APEX of course).
So what happened?
From my perspective:
1. I was rushing so that I could go on vacation without worry.
2. I was doing support work while trying to build the application.
3. I added create_date into the composite unique key without at the very least truncating SYSDATE. This created duplicate records. This was the impetus behind my post the other day named "How do you audit?"
We performed the official root cause analysis today and here's what came out of it:
1. There is no defined or official design process.
2. No official or formal design review was performed.
3. Chet sucks!
It was a good exercise. I believe I am always open and upfront about mistakes. I welcome criticism.
Length between failed deployments: 5 days
I guess it's better to get them out of the way in that short time span. It's never fun and it's always embarrassing. Ultimately, I just have to accept it and move on. ¶ 4/17/2008 08:35:00 PM 0 Comments Links to this post
We were doing between 5 and 8 critical change requests a month, unacceptable. I fought months ago to bring the rates into the data warehouse so that we could own them and eventually build this application (in APEX of course).
So what happened?
From my perspective:
1. I was rushing so that I could go on vacation without worry.
2. I was doing support work while trying to build the application.
3. I added create_date into the composite unique key without at the very least truncating SYSDATE. This created duplicate records. This was the impetus behind my post the other day named "How do you audit?"
We performed the official root cause analysis today and here's what came out of it:
1. There is no defined or official design process.
2. No official or formal design review was performed.
3. Chet sucks!
It was a good exercise. I believe I am always open and upfront about mistakes. I welcome criticism.
Length between failed deployments: 5 days
I guess it's better to get them out of the way in that short time span. It's never fun and it's always embarrassing. Ultimately, I just have to accept it and move on. ¶ 4/17/2008 08:35:00 PM 0 Comments Links to this post
Sunday, April 13, 2008
WellCare Data Breach...
Great...
I haven't spoken with anyone at work about this but I was aware of the event before going on vacation. I did not know any of the particulars, only that it involved Georgia in some way.
I believe everyone works hard to safeguard patient data. The short term drawback is that it will make everyone's life that much more difficult, the long term good will be a better process (I hope).
- Georgia WellCare Data Exposed
- Insurance records of 71000 Ga. families made public
- Georgia: 71,000 private records publicized
- Georgia Patients’ Records Exposed on Web for Weeks
- WellCare Flubs Data Privacy for 10,000 Georgians
I haven't spoken with anyone at work about this but I was aware of the event before going on vacation. I did not know any of the particulars, only that it involved Georgia in some way.
I believe everyone works hard to safeguard patient data. The short term drawback is that it will make everyone's life that much more difficult, the long term good will be a better process (I hope).
Labels: data, discipline, work
¶ 4/13/2008 11:40:00 PM 2 Comments Links to this post
Vacation?
I've been on "vacation" since April 4th. Of course I was sick and slept most of the day. On Sunday, I took the family to Disney World. Last year my parents bought us annual passes to the Magic Kingdom so that we could all go together to get away.
I am an only child. My parents and I never had vacations, we just moved somewhere (8 times). If we did go somewhere, it was to my parents home town town for a week or two to visit Grandma and Grandpa.
Now, here's what I consider a vacation, sitting on a beach drinking Corona's with my beautiful wife (no kids) staring at the ocean. Yes, this is the Corona ads you've probably seen. Quiet. No work. Perfect.
I love the kids, but they are harder "work" than work. On "vacation," I am the pack mule. I carry everything and everyone. A friend at work has shared this story about Man's Stages of Life, I'm in the donkey phase...
I'll say it again because I don't believe my sense of humor always comes out correctly (I'm rarely serious), I love my family, my kids, but a break it is not.
We did have a great time despite all of us coming down with the Disney version of the bird flu. Imagine a virus made up of viri (sp?) from 100 countries...that's what we all have. I'm hacking right now. I took a half day on Thursday and spent the following day with Kate at home. She slept most of the day. Kris and Little Chet spent the day at Disney's Hollywood Studios. Saturday we came home because Little Chet finally caught it. Now we're resting.
I am an only child. My parents and I never had vacations, we just moved somewhere (8 times). If we did go somewhere, it was to my parents home town town for a week or two to visit Grandma and Grandpa.
Now, here's what I consider a vacation, sitting on a beach drinking Corona's with my beautiful wife (no kids) staring at the ocean. Yes, this is the Corona ads you've probably seen. Quiet. No work. Perfect.
I love the kids, but they are harder "work" than work. On "vacation," I am the pack mule. I carry everything and everyone. A friend at work has shared this story about Man's Stages of Life, I'm in the donkey phase...
I'll say it again because I don't believe my sense of humor always comes out correctly (I'm rarely serious), I love my family, my kids, but a break it is not.
Disney H5N1?
We did have a great time despite all of us coming down with the Disney version of the bird flu. Imagine a virus made up of viri (sp?) from 100 countries...that's what we all have. I'm hacking right now. I took a half day on Thursday and spent the following day with Kate at home. She slept most of the day. Kris and Little Chet spent the day at Disney's Hollywood Studios. Saturday we came home because Little Chet finally caught it. Now we're resting.
Upcoming
- Little Chet gets a tooth pulled tomorrow
- Pick up new Dell XPS laptop tomorrow (woohoo!)
- Go back to work (woohoo?)
- I'll be doing my first Application Express presentation for the Suncoast Oracle Users Group, SOUG. Actually, it's my first IT related presentation. If you can make it, please come by and laugh. More information about the presentation can be found here.
Labels: apex, kate, vacation, work
¶ 4/13/2008 12:41:00 PM 2 Comments Links to this post
Sunday, March 30, 2008
Failed Deployment...
236 Days
20 Hours
48 Minutes
30 Seconds
I hate making mistakes but I've made another one. My streak ends almost 237 days from my previous one.
Something so silly too.
In our source system, data was been double loaded somehow. So we decided on a surgical delete. A total of 7 DELETE statements needed to be run; 4 on the source system and 3 on the target system.
The source system went off without a hitch. I babysat the re-load of the source tables and was ready to have our load jobs run in our target system.
What's this? It ran in half the time?! How's that possible?
I pulled up our logs to find that zero rows were loaded into one of our tables. There should have been 45 Million plus.
I started to run down the possible causes:
1. Did the job we have in the scheduler that TRUNCATEs our persistent staging tables run? Nope.
2. Did I fail to instruct the DBAs correctly in the critical CR? Nope. Instructions look good.
3. Next to the logs, it ran fine on Saturday morning but not Sunday morning. What happened yesterday?
4. Ah yes, my CR. Open up the script...nothing out of the ordinary...and then I saw it.
On our target system, we use work tables to pre-generate a keys. It makes things a heck of a lot faster and removes the need for PL/SQL lookups in SQL (no, we don't have incremental builds yet).
So the work table needs to be DELETEd from first based on the keys from the first:
OK, no funny business there.
Then I DELETE from the main table:
As I look at it I wonder WTH I was thinking using an EXISTS clause on the main table. That's the source.
But do you see what I missed?
See it yet?
OK, I left out the "AND my_key = a.my_key" from the inner query. Obviously a stupid approach, but it would have worked. The best way to do it is to just get rid of the EXISTS clause:
Live and learn, live and learn...
20 Hours
48 Minutes
30 Seconds
I hate making mistakes but I've made another one. My streak ends almost 237 days from my previous one.
Something so silly too.
In our source system, data was been double loaded somehow. So we decided on a surgical delete. A total of 7 DELETE statements needed to be run; 4 on the source system and 3 on the target system.
The source system went off without a hitch. I babysat the re-load of the source tables and was ready to have our load jobs run in our target system.
What's this? It ran in half the time?! How's that possible?
I pulled up our logs to find that zero rows were loaded into one of our tables. There should have been 45 Million plus.
I started to run down the possible causes:
1. Did the job we have in the scheduler that TRUNCATEs our persistent staging tables run? Nope.
2. Did I fail to instruct the DBAs correctly in the critical CR? Nope. Instructions look good.
3. Next to the logs, it ran fine on Saturday morning but not Sunday morning. What happened yesterday?
4. Ah yes, my CR. Open up the script...nothing out of the ordinary...and then I saw it.
On our target system, we use work tables to pre-generate a keys. It makes things a heck of a lot faster and removes the need for PL/SQL lookups in SQL (no, we don't have incremental builds yet).
So the work table needs to be DELETEd from first based on the keys from the first:
DELETE FROM some_key_table a
WHERE EXISTS ( SELECT NULL
FROM the_main_table
WHERE business IN ( 'TTT', 'TTR' )
AND dateof = TO_DATE( '24-MAR-08', 'DD-MON-YY' )
AND my_key = a.my_key );
OK, no funny business there.
Then I DELETE from the main table:
DELETE FROM the_main_table a
WHERE EXISTS ( SELECT NULL
FROM the_main_table
WHERE business IN ( 'TTT', 'TTR' )
AND dateof = TO_DATE( '24-MAR-08', 'DD-MON-YY' ) );
As I look at it I wonder WTH I was thinking using an EXISTS clause on the main table. That's the source.
But do you see what I missed?
See it yet?
OK, I left out the "AND my_key = a.my_key" from the inner query. Obviously a stupid approach, but it would have worked. The best way to do it is to just get rid of the EXISTS clause:
DELETE FROM the_main_table a
WHERE business IN ( 'TTT', 'TTR' )
AND dateof = TO_DATE( '24-MAR-08', 'DD-MON-YY' ) );
Live and learn, live and learn...
Labels: funny, humility, sql, work
¶ 3/30/2008 10:21:00 PM 0 Comments Links to this post
Tuesday, March 25, 2008
Use the [Oracle] Database dammit!
Dom Brooks recently posted an article about the Dea(r)th of the Oracle RDBMS. It seemed to struck a chord.
I've written about MySQL Friday or Application Developers vs. Database Developerswhich were similar in thought; the database is a bucket.
Ultimately, my take is that application developers don't know and don't want to learn how to use a database. PL/SQL specifically, is a platform in and of itself. You can do so much in the database now that you essentially need an application only for display, to determine the row color if you will.
The usual caveat follows:
If you are building applications that are supposed to be database independent, then the logic belongs in the application. The database is a bucket.
If you are building business applications specific to Oracle though, use the damn thing. Application/web developers are then forced to work on the design and user interface, not application/transaction logic.
Easy steps to actually utilize your database:
1. Use as many constraints as humanly possible - This will reduce the amount of code you have to write and you'll have the security of knowing the data will be what you constrain it to be.
2. DEFAULT columns in table definitions - create_date or load_date can be default to SYSDATE and thus left out of any application code. I've gone so far as to use SYS_CONTEXT( 'MY_CONTEXT', 'USERID' ) as the DEFAULT value for the create_user column. That along with a NOT NULL (or CHECK) constraint, makes life that much easier.
3. Did I mention constraints? Primary Key and Foreign Key constraints are very important to maintain data integrity (ensure you have the data you expect). Don't forget to index those foreign keys.
4. Security - VPD (Virtual Private Database) or Fine Grained Access Control. No longer do you need to maintain two separate schemas (or databases), just add a column and only allow those with the value set see that data. If you are using ApEx, this is incredibly easy to do.
5. Security (Roles and Privileges) - No more table based authorization, let the database do it through roles and privileges. GRANT EXECUTE ON my_package TO some_user
That's my short list for today. Like Dom, this makes me angry. If there were some rational logic behind it, great, convince me. I haven't seen it yet though.
I've written about MySQL Friday or Application Developers vs. Database Developerswhich were similar in thought; the database is a bucket.
Ultimately, my take is that application developers don't know and don't want to learn how to use a database. PL/SQL specifically, is a platform in and of itself. You can do so much in the database now that you essentially need an application only for display, to determine the row color if you will.
The usual caveat follows:
If you are building applications that are supposed to be database independent, then the logic belongs in the application. The database is a bucket.
If you are building business applications specific to Oracle though, use the damn thing. Application/web developers are then forced to work on the design and user interface, not application/transaction logic.
Easy steps to actually utilize your database:
1. Use as many constraints as humanly possible - This will reduce the amount of code you have to write and you'll have the security of knowing the data will be what you constrain it to be.
2. DEFAULT columns in table definitions - create_date or load_date can be default to SYSDATE and thus left out of any application code. I've gone so far as to use SYS_CONTEXT( 'MY_CONTEXT', 'USERID' ) as the DEFAULT value for the create_user column. That along with a NOT NULL (or CHECK) constraint, makes life that much easier.
3. Did I mention constraints? Primary Key and Foreign Key constraints are very important to maintain data integrity (ensure you have the data you expect). Don't forget to index those foreign keys.
4. Security - VPD (Virtual Private Database) or Fine Grained Access Control. No longer do you need to maintain two separate schemas (or databases), just add a column and only allow those with the value set see that data. If you are using ApEx, this is incredibly easy to do.
5. Security (Roles and Privileges) - No more table based authorization, let the database do it through roles and privileges. GRANT EXECUTE ON my_package TO some_user
That's my short list for today. Like Dom, this makes me angry. If there were some rational logic behind it, great, convince me. I haven't seen it yet though.
Labels: constraints, database, development, oracle, work
¶ 3/25/2008 03:16:00 PM 2 Comments Links to this post
Wednesday, March 19, 2008
The Return to ApEx
It's been almost a year, but I've finally gotten a chance to dive back into ApEx!
I've been working primarily on our financial reconciliation for our Medicaid business. That's now very stable as we have everything in our fancy new star schema.
One of the support type activities we've been doing for the past 6 months is maintaining their rate tables...manually. They send (and resend) a csv file and we then match and insert those new records into their rate tables. I don't get to recreate the entire thing unfortunately, it's horribly designed, but I do get to do something.
So instead of doing these manually I finally convinced my boss that this could be done relatively easy with ApEx. I've demo'd it for him in the past, so he's aware of it's capabilities (my evangelism of it doesn't hurt though). Of course our VP steps in and says we have to go through the technical review board. Fair enough, I'm all for standards.
Thankfully my manager convinced the architects that we don't have the Java or Ruby resources to do this, plus, it would take weeks!
So, here's to ApEx, and the further infiltration of it at WellCare! ¶ 3/19/2008 12:35:00 AM 2 Comments Links to this post
I've been working primarily on our financial reconciliation for our Medicaid business. That's now very stable as we have everything in our fancy new star schema.
One of the support type activities we've been doing for the past 6 months is maintaining their rate tables...manually. They send (and resend) a csv file and we then match and insert those new records into their rate tables. I don't get to recreate the entire thing unfortunately, it's horribly designed, but I do get to do something.
So instead of doing these manually I finally convinced my boss that this could be done relatively easy with ApEx. I've demo'd it for him in the past, so he's aware of it's capabilities (my evangelism of it doesn't hurt though). Of course our VP steps in and says we have to go through the technical review board. Fair enough, I'm all for standards.
Thankfully my manager convinced the architects that we don't have the Java or Ruby resources to do this, plus, it would take weeks!
So, here's to ApEx, and the further infiltration of it at WellCare! ¶ 3/19/2008 12:35:00 AM 2 Comments Links to this post
Tuesday, March 4, 2008
Bowling for IT
Another non-Oracle related post. Just fun at work.
Last Friday we had another one of our IT all-hands meetings. My goal at each one is to make either the rumor list (of the top ten variety) or to be somehow be involved (hopefully good) in other ways.
Two months ago I was promoted to SVP of IT, because I was able to talk my CIO into it. Last month, I was promoted to CEO because I happen to resemble our new CEO. This month, the "light" piece was a "Where are they now?" complete with old/new pictures of IT employees. (Needless to say I am an only child...I crave attention!)
To say I've gained weight since starting a career/marriage/family would be an understatement. I went from a lean and mean 170 to about 250 now. The first pic I had just completed a sprint triathlon in Clermont, Florida. The second was sometime after the birth of my first child.
I take about every opportunity I can to send out the first one to new friends. "I didn't always look like a slob. That got to be my "before" picture and my "after" picture was my mugshot from my ID badge (yikes).
There I was 10 feet tall and looking great! I no longer had to send the picture out to anyone (and risk possible graffiti, though I guess posting it here doesn't help matters).
The important part was that I made all-hands again. I think that's 12 in a row.
And finally to the title of the post. After our all-hands meeting we went bowling. Food and bowling were free. I did notice however that there are quite a few, um..., drinkers among IT. I would certainly say that I fall into that category. At one point, it took so long to get a drink (only one bartender for 100 some odd people) I tried to ban the sale of mixed drinks so it would speed things up. However, my ploy didn't work.
I just bought two beers and waited for everyone else to follow-up with pitchers!
Gotta have fun at work right? ¶ 3/04/2008 09:08:00 PM 0 Comments Links to this post
Last Friday we had another one of our IT all-hands meetings. My goal at each one is to make either the rumor list (of the top ten variety) or to be somehow be involved (hopefully good) in other ways.
Two months ago I was promoted to SVP of IT, because I was able to talk my CIO into it. Last month, I was promoted to CEO because I happen to resemble our new CEO. This month, the "light" piece was a "Where are they now?" complete with old/new pictures of IT employees. (Needless to say I am an only child...I crave attention!)
To say I've gained weight since starting a career/marriage/family would be an understatement. I went from a lean and mean 170 to about 250 now. The first pic I had just completed a sprint triathlon in Clermont, Florida. The second was sometime after the birth of my first child.
I take about every opportunity I can to send out the first one to new friends. "I didn't always look like a slob. That got to be my "before" picture and my "after" picture was my mugshot from my ID badge (yikes).
There I was 10 feet tall and looking great! I no longer had to send the picture out to anyone (and risk possible graffiti, though I guess posting it here doesn't help matters).
The important part was that I made all-hands again. I think that's 12 in a row.
And finally to the title of the post. After our all-hands meeting we went bowling. Food and bowling were free. I did notice however that there are quite a few, um..., drinkers among IT. I would certainly say that I fall into that category. At one point, it took so long to get a drink (only one bartender for 100 some odd people) I tried to ban the sale of mixed drinks so it would speed things up. However, my ploy didn't work.
I just bought two beers and waited for everyone else to follow-up with pitchers!
Gotta have fun at work right? ¶ 3/04/2008 09:08:00 PM 0 Comments Links to this post
Wednesday, February 27, 2008
EDI Fun
or Electronic Data Interchange, just a fancy phrase for sending and receiving files. We (IT) do love to complicate things don't we?
I've put the change data capture stuff on hold as my never-ending project goes into it's 12th week past deadline. It's at nine 9s: 99.9999999. It's finance related stuff and nothing less than 100% is acceptable. I'm tired.
Part of my project was to move from an already built in house table to the raw (files) tables. My feisty colleague took on that fun challenge for 6 months or so. He's heading up a new project though so he's had to pass the baton on to me. I've accepted it...reluctantly. ;)
Anyway, we store these inbound files all over the place (seemingly to me). I started writing a little Java application that would scan a directory, read these x12-820 files and tell me the interchange date, control number, total amount and some other useful information.
I plan on either putting this in the database and wrapping it up in PL/SQL or creating a service (Java Service Wrapper) and pushing this useful data to a table. So if you have to deal with the wonderful x12/820 formats, you may want to check back soon for the code. I can't promise it will be good, but it will work!
I've put the change data capture stuff on hold as my never-ending project goes into it's 12th week past deadline. It's at nine 9s: 99.9999999. It's finance related stuff and nothing less than 100% is acceptable. I'm tired.
Part of my project was to move from an already built in house table to the raw (files) tables. My feisty colleague took on that fun challenge for 6 months or so. He's heading up a new project though so he's had to pass the baton on to me. I've accepted it...reluctantly. ;)
Anyway, we store these inbound files all over the place (seemingly to me). I started writing a little Java application that would scan a directory, read these x12-820 files and tell me the interchange date, control number, total amount and some other useful information.
I plan on either putting this in the database and wrapping it up in PL/SQL or creating a service (Java Service Wrapper) and pushing this useful data to a table. So if you have to deal with the wonderful x12/820 formats, you may want to check back soon for the code. I can't promise it will be good, but it will work!
Labels: edi, java, plsql, tools, utilities, work
¶ 2/27/2008 08:25:00 PM 0 Comments Links to this post
Wednesday, February 20, 2008
Application Developers vs Database Developers
It started innocently enough with this article. I sent it out to about 20 colleagues.
The best line from the article:
"Jerry: "Yeah, databases cause lots of headaches. They crash all the time, corrupt data, etc. Using text files is better."
One of my more recently arrived colleagues (I'll call him Mr. M) replied to everyone with this statement:
"Kind of funny actually, databases are less and less important at the large investment banks, where they basically load everything up into a data grid across a several hundred node cluster. Writing to the db is way too slow."
This started a day long exchange of emails. What follows is the entire thread (up until my last post tonight).
Me:
"I would just argue that they don’t necessarily know how to write to databases. I would however love to see benchmarking done on both methods. Would be an interesting test..."
Mr. M:
"Well, my understanding is they just can’t scale out the db enough. Even something like Oracle RAC won’t work. And outside of the military, these are probably the top 1% of programmers in the world building this stuff."
Me:
"A benchmark would be the only way I would believe it.
If you said the top 1% of database developers tried it and failed, I would be more likely to agree.
My experience is that application developers != database developers. Different type of thinking involved."
Mr. M:
"'A benchmark would be the only way I would believe it.'
Do you need a benchmark before you would believe in-memory retrieval is faster than disk retrieval? Essentially, this is what we’re talking about.
'If you said the top 1% of database developers tried it and failed, I would be more likely to agree. My experience is that application developers != database developers. Different type of thinking involved.'
Why? It’s an issue to do with application performance not simply database performance. Database concerns are a subset of application concerns, essentially a specialization, requiring less encompassing knowledge. ;)
From the article you linked to (http://www.watersonline.com/public/showPage.html?page=432587)
"Better data management is the answer, says Lewis Foti, manager of high-performance computing and grid at The Royal Bank of Scotland (RBS) global banking and markets. "For very large compute arrays, the key issue is data starvation and saturation. This problem requires data grids with high bandwidth and scalable, parallel access,
...
Banks are learning that data management in a distributed grid environment is very different from online transaction processing. "With so many data sources, distribution channels, demands for aggregation and analytics, surges in data volumes and complex dynamics between the flows, we need to manage 'data in motion' and give up the notion that data is somehow stored. It's dynamic, not static," says Michael Di Stefano, vice president and architect for financial services at GemStone Systems
...
There is even some debate over how small a unit of work can be put on today's grids. Di Stefano at GemStone, for example, says, "One client has gone from 200 trades per second in a program trading application to more than 6,000 trades per second. This shows what the technology can do."
Yep, the writing is on the wall. Oracle knows it too.
http://www.google.com/search?hl=en&q=oracle+buys+tangosol&btnG=Google+Search"
Me:
"Good points. If it is in-memory it would be faster. I have not had the pleasure to work on such a system.
I do disagree with the database concerns being a subset of application concerns. The data drives the app. We’re probably getting religious at this point (or am I)."
Mr. M:
"‘The data drives the app.”
Exactly, but who’s to say where the data comes from or in what format? My application data may reside completely in xml files, or maybe I get it from some third party web services a la the en vogue “mashup.” Heck, I may not even need to worry about a database anymore…. http://www.amazon.com/gp/browse.html?node=16427261 The database is only one particular concern of the overall application. And it’s the application that matters. Data is useless if it just sits on a disk somewhere. It’s the ways in which the application lets the users view and manipulate the data that adds value to the business.
Yep, definitely a different type of thinking between application developers and database developers."
Me:
"Definitely religious now.
Applications come and go, data stays the same. Think Green Screens, EJBs, Ruby…what’s next?"
Mr. M:
"'Applications come and go'
Exactly. Businesses are not static, nor are the markets they compete in. Changing applications are a function of changing business processes and changing markets.
'data stays the same.'
Nonsense. Otherwise UPDATE would not be an SQL reserved word. If you mean database technology stays the same, well, I’m more inclined to agree with that.
'Think Green Screens, EJBs, Ruby...what’s next?'
Whatever comes along to let the business more effectively respond to current market realities. Application platforms have evolved much faster than database platforms have. They’ve had to, their sphere of operation is much broader than that of databases, this is only natural, they deal with much broader concerns than do databases. Databases in the internet era function in essentially the same role they did in the era of dumb terminals. Clearly application platforms have evolved orders of magnitude more. Hence the statement, database concerns are a subset of application concerns.
Here’s a simple test….if I take some business application and I’m forced to throw away one or the other, either the database or the appl- wait a second, it doesn’t even make sense to finish it, does it? The business can live without the database. I could do all kinds of things with the data, I could stick it anywhere. The business can’t live without the application though. Another way to look at is, what do the business users look at, test, approve, and use? The database? Of course not, they look at the application. They could care less whether the data sits on disk in an RDBMS, xml, or flat files."
Me:
"We obviously violently disagree.
Without the database (and I use database and data interchangebly), the business could no longer function. The app is meaningless. How would you contact your customer? You couldn’t find it.
'Exactly. Businesses are not static, nor are the markets they compete in. Changing applications are a function of changing business processes and changing markets.'
Poorly designed applications…that is all."
A Feisty Colleague:
"Using data and database interchangeably is incorrect. A database is a mechanism for data storage. XML data sets and flat files are mechanisms for data storage, too. So is a file cabinet, because, the data doesn’t have to be electronic, it could be … gasp! … on paper, and the application to use that data would be hands for holding the paper and a pencil to update and add data to the page."
Me:
"No it isn’t. I take into account xml files, flat files, web services (but not paper, unless it’s scanned) and all that. It would be consumed by the database and then accessed by the application via SQL.
(that’s for Mr. M and the feisty one)"
At which point someone forwarded the home page for Oracle's TimesTen In-Memory Database.
Me:
"A database on/in the mid-tier...Perfect!"
Mr. M:
"Implicit acknowledgment that disk IO operations that come with traditional database access simply can’t match the performance of in-memory data access (a point which you previously were unconvinced of but now seem perfectly accepting of the idea once you see it’s got Oracle’s imprimatur on it).
Of course, why any application developer would want to program against an SQL interface if they weren’t forced to is beyond me. It is orthogonal to the programming model of most application platform languages.
Surely Oracle recognize this fact too or they wouldn’t be buying Tangosol and other data grid technologies. Of course, most of those products are far more technically advanced than TimesTen or anything Oracle has in that space.
Incidentally, it’s illustrative to note that Coherence and other products like it were for the most part designed and built by application programmers. The development of all these products is pretty much driven by the needs of the large investment banks on Wall Street. These trading applications simply had too many concurrent transactions to use an RDBMS (a problem quite a number of public domains now share, most famously google.com, nope, no RDBMS there, yet miraculously there is still data). The database just simply would not scale to such a degree. So the application developers, by necessity, came up with an alternate solution that did work, a fully transactional cache of data replicated across a cluster with node numbers in the thousands, and no relational model whatsoever to speak of. A perfect example of how database concerns are only one, sometimes small, concern amongst many that application developers must be aware of and ready to solve."
Me:
"Like you said initially, the top 1%.
Many of us will never touch a system like this.
I will certainly concede that it is faster (still would love to see benchmarking though), but that still leaves 99% of the applications out there that do not require that kind of performance."
Me (again):
"And don’t forget, I use data and database interchangeably. Applications are nothing without the data right?
As to the object/relational impedance mismatch...well, more people that don’t know how to work in sets. Looping is what they understand. I understand the application side more than you seem to give me credit for.
I’m not saying applications aren’t important, they are. Data (databases) and applications go hand in hand. If the application went away though, they could still access their data via SELECT statements (yes, via an application client tool), however painful that may be. Applications make retrieving data that much easier for our users.
If anyone wants to unsubscribe from this mailing list, just let us know. This is fun for me (I’m guessing Mr. M too)."
Needless to say it was a fun day. It didn't get [too] personal. More than anything I'm happy to have an equally passionate colleague.
Besides, he claims he was just fracking around with me. ;)
The best line from the article:
"Jerry: "Yeah, databases cause lots of headaches. They crash all the time, corrupt data, etc. Using text files is better."
One of my more recently arrived colleagues (I'll call him Mr. M) replied to everyone with this statement:
"Kind of funny actually, databases are less and less important at the large investment banks, where they basically load everything up into a data grid across a several hundred node cluster. Writing to the db is way too slow."
This started a day long exchange of emails. What follows is the entire thread (up until my last post tonight).
Me:
"I would just argue that they don’t necessarily know how to write to databases. I would however love to see benchmarking done on both methods. Would be an interesting test..."
Mr. M:
"Well, my understanding is they just can’t scale out the db enough. Even something like Oracle RAC won’t work. And outside of the military, these are probably the top 1% of programmers in the world building this stuff."
Me:
"A benchmark would be the only way I would believe it.
If you said the top 1% of database developers tried it and failed, I would be more likely to agree.
My experience is that application developers != database developers. Different type of thinking involved."
Mr. M:
"'A benchmark would be the only way I would believe it.'
Do you need a benchmark before you would believe in-memory retrieval is faster than disk retrieval? Essentially, this is what we’re talking about.
'If you said the top 1% of database developers tried it and failed, I would be more likely to agree. My experience is that application developers != database developers. Different type of thinking involved.'
Why? It’s an issue to do with application performance not simply database performance. Database concerns are a subset of application concerns, essentially a specialization, requiring less encompassing knowledge. ;)
From the article you linked to (http://www.watersonline.com/public/showPage.html?page=432587)
"Better data management is the answer, says Lewis Foti, manager of high-performance computing and grid at The Royal Bank of Scotland (RBS) global banking and markets. "For very large compute arrays, the key issue is data starvation and saturation. This problem requires data grids with high bandwidth and scalable, parallel access,
...
Banks are learning that data management in a distributed grid environment is very different from online transaction processing. "With so many data sources, distribution channels, demands for aggregation and analytics, surges in data volumes and complex dynamics between the flows, we need to manage 'data in motion' and give up the notion that data is somehow stored. It's dynamic, not static," says Michael Di Stefano, vice president and architect for financial services at GemStone Systems
...
There is even some debate over how small a unit of work can be put on today's grids. Di Stefano at GemStone, for example, says, "One client has gone from 200 trades per second in a program trading application to more than 6,000 trades per second. This shows what the technology can do."
Yep, the writing is on the wall. Oracle knows it too.
http://www.google.com/search?hl=en&q=oracle+buys+tangosol&btnG=Google+Search"
Me:
"Good points. If it is in-memory it would be faster. I have not had the pleasure to work on such a system.
I do disagree with the database concerns being a subset of application concerns. The data drives the app. We’re probably getting religious at this point (or am I)."
Mr. M:
"‘The data drives the app.”
Exactly, but who’s to say where the data comes from or in what format? My application data may reside completely in xml files, or maybe I get it from some third party web services a la the en vogue “mashup.” Heck, I may not even need to worry about a database anymore…. http://www.amazon.com/gp/browse.html?node=16427261 The database is only one particular concern of the overall application. And it’s the application that matters. Data is useless if it just sits on a disk somewhere. It’s the ways in which the application lets the users view and manipulate the data that adds value to the business.
Yep, definitely a different type of thinking between application developers and database developers."
Me:
"Definitely religious now.
Applications come and go, data stays the same. Think Green Screens, EJBs, Ruby…what’s next?"
Mr. M:
"'Applications come and go'
Exactly. Businesses are not static, nor are the markets they compete in. Changing applications are a function of changing business processes and changing markets.
'data stays the same.'
Nonsense. Otherwise UPDATE would not be an SQL reserved word. If you mean database technology stays the same, well, I’m more inclined to agree with that.
'Think Green Screens, EJBs, Ruby...what’s next?'
Whatever comes along to let the business more effectively respond to current market realities. Application platforms have evolved much faster than database platforms have. They’ve had to, their sphere of operation is much broader than that of databases, this is only natural, they deal with much broader concerns than do databases. Databases in the internet era function in essentially the same role they did in the era of dumb terminals. Clearly application platforms have evolved orders of magnitude more. Hence the statement, database concerns are a subset of application concerns.
Here’s a simple test….if I take some business application and I’m forced to throw away one or the other, either the database or the appl- wait a second, it doesn’t even make sense to finish it, does it? The business can live without the database. I could do all kinds of things with the data, I could stick it anywhere. The business can’t live without the application though. Another way to look at is, what do the business users look at, test, approve, and use? The database? Of course not, they look at the application. They could care less whether the data sits on disk in an RDBMS, xml, or flat files."
Me:
"We obviously violently disagree.
Without the database (and I use database and data interchangebly), the business could no longer function. The app is meaningless. How would you contact your customer? You couldn’t find it.
'Exactly. Businesses are not static, nor are the markets they compete in. Changing applications are a function of changing business processes and changing markets.'
Poorly designed applications…that is all."
A Feisty Colleague:
"Using data and database interchangeably is incorrect. A database is a mechanism for data storage. XML data sets and flat files are mechanisms for data storage, too. So is a file cabinet, because, the data doesn’t have to be electronic, it could be … gasp! … on paper, and the application to use that data would be hands for holding the paper and a pencil to update and add data to the page."
Me:
"No it isn’t. I take into account xml files, flat files, web services (but not paper, unless it’s scanned) and all that. It would be consumed by the database and then accessed by the application via SQL.
(that’s for Mr. M and the feisty one)"
At which point someone forwarded the home page for Oracle's TimesTen In-Memory Database.
Me:
"A database on/in the mid-tier...Perfect!"
Mr. M:
"Implicit acknowledgment that disk IO operations that come with traditional database access simply can’t match the performance of in-memory data access (a point which you previously were unconvinced of but now seem perfectly accepting of the idea once you see it’s got Oracle’s imprimatur on it).
Of course, why any application developer would want to program against an SQL interface if they weren’t forced to is beyond me. It is orthogonal to the programming model of most application platform languages.
Surely Oracle recognize this fact too or they wouldn’t be buying Tangosol and other data grid technologies. Of course, most of those products are far more technically advanced than TimesTen or anything Oracle has in that space.
Incidentally, it’s illustrative to note that Coherence and other products like it were for the most part designed and built by application programmers. The development of all these products is pretty much driven by the needs of the large investment banks on Wall Street. These trading applications simply had too many concurrent transactions to use an RDBMS (a problem quite a number of public domains now share, most famously google.com, nope, no RDBMS there, yet miraculously there is still data). The database just simply would not scale to such a degree. So the application developers, by necessity, came up with an alternate solution that did work, a fully transactional cache of data replicated across a cluster with node numbers in the thousands, and no relational model whatsoever to speak of. A perfect example of how database concerns are only one, sometimes small, concern amongst many that application developers must be aware of and ready to solve."
Me:
"Like you said initially, the top 1%.
Many of us will never touch a system like this.
I will certainly concede that it is faster (still would love to see benchmarking though), but that still leaves 99% of the applications out there that do not require that kind of performance."
Me (again):
"And don’t forget, I use data and database interchangeably. Applications are nothing without the data right?
As to the object/relational impedance mismatch...well, more people that don’t know how to work in sets. Looping is what they understand. I understand the application side more than you seem to give me credit for.
I’m not saying applications aren’t important, they are. Data (databases) and applications go hand in hand. If the application went away though, they could still access their data via SELECT statements (yes, via an application client tool), however painful that may be. Applications make retrieving data that much easier for our users.
If anyone wants to unsubscribe from this mailing list, just let us know. This is fun for me (I’m guessing Mr. M too)."
Needless to say it was a fun day. It didn't get [too] personal. More than anything I'm happy to have an equally passionate colleague.
Besides, he claims he was just fracking around with me. ;)
Labels: database, development, funny, partition, work
¶ 2/20/2008 10:29:00 PM 5 Comments Links to this post
Monday, February 4, 2008
Is It Arrogance?
I wrote on Friday night about my experiences that day.
I am a very opinionated person. I believe, whole-heartedly, that the database is severely under-utilized, especially at my current employer.
I believe that one of the big draws of MySQL is that it's easy for web/application people to pick up. I also believe, in our situation, that's it's a way for application developers to skirt the whole "data" problem. They'll just pawn it off on the Production DBAs to keep the database running.
Amusingly, some of our application developers brought down one of our Oracle instances, more than once. Pretty tough thing to do I always thought.
I've read articles on bind variables since the beginning, but since it had been drilled into me, I found it quaint. Who would do that?
From a C# app someone passed in hundreds of thousands of un-bound INSERT statements. It flooded the shared pool (is that right?) and brought it to a screeching halt.
Anyway, back to the point.
I've been very vocal lately about MySQL. A few of my friends have begun to warn me that I may be crossing the line towards arrogance. That I will come off as someone resistant to change.
I don't see it. But sometimes we're the last to see our own reflection.
I don't believe that I am resistant to change. I like change. I just want it to be proven, that's all. I embraced ApEx because it made my life easier. That's all I want.
Does this make me arrogant?
I am a very opinionated person. I believe, whole-heartedly, that the database is severely under-utilized, especially at my current employer.
I believe that one of the big draws of MySQL is that it's easy for web/application people to pick up. I also believe, in our situation, that's it's a way for application developers to skirt the whole "data" problem. They'll just pawn it off on the Production DBAs to keep the database running.
Amusingly, some of our application developers brought down one of our Oracle instances, more than once. Pretty tough thing to do I always thought.
I've read articles on bind variables since the beginning, but since it had been drilled into me, I found it quaint. Who would do that?
From a C# app someone passed in hundreds of thousands of un-bound INSERT statements. It flooded the shared pool (is that right?) and brought it to a screeching halt.
Anyway, back to the point.
I've been very vocal lately about MySQL. A few of my friends have begun to warn me that I may be crossing the line towards arrogance. That I will come off as someone resistant to change.
I don't see it. But sometimes we're the last to see our own reflection.
I don't believe that I am resistant to change. I like change. I just want it to be proven, that's all. I embraced ApEx because it made my life easier. That's all I want.
Does this make me arrogant?
Labels: database, mysql, oracle, sql, work
¶ 2/04/2008 10:57:00 PM 3 Comments Links to this post
Friday, February 1, 2008
MySQL Friday
Each month we have an IT All-Hands meeting.
Last month I was promoted to Senior Vice President (SVP), because of my superior management techniques.
Today I was promoted to CEO! Unfortunately it only lasted for a few minutes. I happen to resemble our new CEO (and I'm always pining for a promotion) and they thought it would be funny (again) to bring me up.
I hugged the guy behind me, shook hands with people next to me and ran up to the front. I wanted to shriek, like the people do on The Price is Right, but I didn't have it in me. You gotta have fun at work right?
Well, after that it got serious. Our new Director (at WellCare, Directors are executives, one step up from managers and one below VPs) who heads our architecture team (and release management) got up to discuss where he would be taking us.
Slide one:
From 3 database engines to 1.
From 4 programming languages to 2.
From 3 OSs to 1.
Wanna guess what question I had?
"So, what database engine are we going to use?"
I knew the answer, but I take every single opportunity I get to make my point.
"MySQL."
Being on the datawarehouse team, I was confident that Oracle was not going away.
He went on to explain:
"Legacy applications would be maintained but everything going forward would be done in MySQL."
A flurry of questions came from the crowd so I was unable to followup immediately. I could feel the room come alive...it was weird (I think I'm still hopped up from the events that took place today).
Our CIO asked if there were any more questions or comments.
I spoke up.
I have two points.
1. If it's about cost, move all of the one-off applications into just a few Oracle instances. From what I can tell, we have somewhere in the neighborhood of 100. Let's say 5 databases, datawarehouse, our production OLTP and one for others. All you need to do is assign them different schemas, voila! Cost is much lower and there is a very big chance to reuse code.
2. Actually, I can't remember what my other point was. I think it had something to do with putting the logic in the database, that Java was the fad a few years ago, Ruby was the big thing now, what would it be in 5 years? Will we have to rewrite all of the logic then? (I guess I do sorta remember).
After that, someone asked about the two programming languages. Not a great answer from the crowd's reaction. Then someone asked about the OS.
The crowd was riotous (if that's a word). The CIO had to calm us all down.
I made a remark that he hadn't danced yet (one of our former hazing techniques for new employees) because I didn't want it to be completely personal, or just to ease something that I started.
After the meeting, I spoke with the Director. Oracle will be gone in 20 years because of the open source databases, it's being commoditized (not sure what that means). SOA is the wave of the future.
It was a polite conversation. I told him I look forward to learning from him but that I will probably never be sold on that idea. Fewer moving parts, simplicity, that's what I want.
I then spoke with the CIO, told him that once the decision was made, I would support it and keep my mouth shut (or find a new job).
I sent an email to the VP of the Director's group (after a couple of beers...idiot!) explaining my rationale.
One of the biggest reasons we chose to come to Tampa, to WellCare specifically, was because it was so young and immature. I would have the opportunity, if I could prove myself, to shape the future of IT here.
It's nice to have a voice.
Anyway, it's Friday, I'm prepped to spend all weekend at work to get this project delivered that was due in November. Have a good weekend!
Last month I was promoted to Senior Vice President (SVP), because of my superior management techniques.
Today I was promoted to CEO! Unfortunately it only lasted for a few minutes. I happen to resemble our new CEO (and I'm always pining for a promotion) and they thought it would be funny (again) to bring me up.
I hugged the guy behind me, shook hands with people next to me and ran up to the front. I wanted to shriek, like the people do on The Price is Right, but I didn't have it in me. You gotta have fun at work right?
Well, after that it got serious. Our new Director (at WellCare, Directors are executives, one step up from managers and one below VPs) who heads our architecture team (and release management) got up to discuss where he would be taking us.
Slide one:
From 3 database engines to 1.
From 4 programming languages to 2.
From 3 OSs to 1.
Wanna guess what question I had?
"So, what database engine are we going to use?"
I knew the answer, but I take every single opportunity I get to make my point.
"MySQL."
Being on the datawarehouse team, I was confident that Oracle was not going away.
He went on to explain:
"Legacy applications would be maintained but everything going forward would be done in MySQL."
A flurry of questions came from the crowd so I was unable to followup immediately. I could feel the room come alive...it was weird (I think I'm still hopped up from the events that took place today).
Our CIO asked if there were any more questions or comments.
I spoke up.
I have two points.
1. If it's about cost, move all of the one-off applications into just a few Oracle instances. From what I can tell, we have somewhere in the neighborhood of 100. Let's say 5 databases, datawarehouse, our production OLTP and one for others. All you need to do is assign them different schemas, voila! Cost is much lower and there is a very big chance to reuse code.
2. Actually, I can't remember what my other point was. I think it had something to do with putting the logic in the database, that Java was the fad a few years ago, Ruby was the big thing now, what would it be in 5 years? Will we have to rewrite all of the logic then? (I guess I do sorta remember).
After that, someone asked about the two programming languages. Not a great answer from the crowd's reaction. Then someone asked about the OS.
The crowd was riotous (if that's a word). The CIO had to calm us all down.
I made a remark that he hadn't danced yet (one of our former hazing techniques for new employees) because I didn't want it to be completely personal, or just to ease something that I started.
After the meeting, I spoke with the Director. Oracle will be gone in 20 years because of the open source databases, it's being commoditized (not sure what that means). SOA is the wave of the future.
It was a polite conversation. I told him I look forward to learning from him but that I will probably never be sold on that idea. Fewer moving parts, simplicity, that's what I want.
I then spoke with the CIO, told him that once the decision was made, I would support it and keep my mouth shut (or find a new job).
I sent an email to the VP of the Director's group (after a couple of beers...idiot!) explaining my rationale.
One of the biggest reasons we chose to come to Tampa, to WellCare specifically, was because it was so young and immature. I would have the opportunity, if I could prove myself, to shape the future of IT here.
It's nice to have a voice.
Anyway, it's Friday, I'm prepped to spend all weekend at work to get this project delivered that was due in November. Have a good weekend!
Labels: cio, database, funny, mysql, oracle, sql, work
¶ 2/01/2008 10:52:00 PM 2 Comments Links to this post
Thursday, January 31, 2008
Love Your DBA
I consider myself a Developer/DBA.
That said, you've probably either read about or experienced the typical riff between the developer and the DBA.
At my current employer, I am finally surrounded by true Production DBAs. Initially, I found it difficult to work them. When I would ask "Why can't I do that?" I would rarely get a response.
Over time though, things have changed...for the better.
I believe it's called trust.
Trust that I am trying to do the right thing.
Trust that I want to learn.
Trust that I will listen to their suggestions.
Trust that I won't hack their DEV/QA instances using CREATE ANY PROCEDURE and EXECUTE ANY PROCEDURE.
Trust that I want to build a scalable and robust application.
So love your DBA. Give them time to get to know you. Give them time to learn your style, your methodology. Maybe someday they'll love you back and your job will get infinitely easier.
That said, you've probably either read about or experienced the typical riff between the developer and the DBA.
At my current employer, I am finally surrounded by true Production DBAs. Initially, I found it difficult to work them. When I would ask "Why can't I do that?" I would rarely get a response.
Over time though, things have changed...for the better.
I believe it's called trust.
Trust that I am trying to do the right thing.
Trust that I want to learn.
Trust that I will listen to their suggestions.
Trust that I won't hack their DEV/QA instances using CREATE ANY PROCEDURE and EXECUTE ANY PROCEDURE.
Trust that I want to build a scalable and robust application.
So love your DBA. Give them time to get to know you. Give them time to learn your style, your methodology. Maybe someday they'll love you back and your job will get infinitely easier.
Labels: database, dba, development, work
¶ 1/31/2008 12:15:00 AM 6 Comments Links to this post
Sunday, January 27, 2008
Open Source Obsession?
Since our new CIO came on board last January, there seems to a big movement towards Open Source tools.
While I have nothing against them, I've used various tools in the past; I just don't see what our obsession is with them.
Let's start with Ruby on Rails. An open source framework built on top of Ruby. It's used for web development. It's supposed to be a much more user intuitive language which makes it so easy. Fair enough. I'm always for something that will make my job easier. Our corporate website and provider portals were previously created on the dot net framework.
It was decided last year to replace our entire web infrastructure with Ruby on Rails. I'm still trying to figure out why. It's not that I am a pro-Microsoft guy, but the site worked. There were complaints about it missing this or that functionality, but that's fairly easy to remedy. As far as I know, dot net can support AJAX functionality (which I believe was at the heart of everything).
The demos of the new site were very cool (apparently we paid someone a lot of money to design the site...a LOT of money). It looked all web 2.0ey, big buttons, small text (which is a suprise given we are an HMO managing Medicare). It looked a lot like the 37signals applications in fact. I guess I've read Tom Kyte for far too long and his rant about putting business logic in the database because the front end will always change. Seems true. Java or dot net were all the rage a few years back, now it's Ruby, in a couple of years it will be something else (ApEx!) at which point we will have to rewrite the whole thing.
Next up, MySQL. It's a given that this database has come a long way. Version 5 even has stored procedures. It's a great free database that supports many websites out there. Free is good. Well, mostly free anyway, we do pay support costs right now. Almost every new project is built on top of MySQL. Why? I'm not sure other than free.
I asked the question to the CIO in one of our All-Hands meetings and his response was cost.
Fair enough, Oracle is expensive. The way we use Oracle is even more so. Each project seems to get it's own database. Why they don't get a schema on an existing database I don't quite understand. I've been told that it is a logistical nightmare to pull down a database that affects so many different applications. Each group wants their own version, etc., etc.
I can understand the Data Warehouse having their own database and perhaps our main appplication having it's own database; but every single application? Why not a one off database that houses all the smaller applications in different schemas? That's what Oracle was built for? Plus you can reuse code, reduce the number of instances (thus reducing the cost)...I just don't understand.
I believe my main complaint is that they are still just treating the database (whether Oracle or MySQL) like a bucket. Web people should not be writing SQL; Ruby people should not be writing SQL; just like I shouldn't be writing Ruby code. I don't know it.
I would be willing to bet that I could re-create many of our smaller applications in a much shorter period of time in Oracle and ApEx given the same requirements.
So I rant on. If I truly thought that this was an effort to make IT cheaper and more sustainable, I would be on board. I just don't see that that is the case...
While I have nothing against them, I've used various tools in the past; I just don't see what our obsession is with them.
Let's start with Ruby on Rails. An open source framework built on top of Ruby. It's used for web development. It's supposed to be a much more user intuitive language which makes it so easy. Fair enough. I'm always for something that will make my job easier. Our corporate website and provider portals were previously created on the dot net framework.
It was decided last year to replace our entire web infrastructure with Ruby on Rails. I'm still trying to figure out why. It's not that I am a pro-Microsoft guy, but the site worked. There were complaints about it missing this or that functionality, but that's fairly easy to remedy. As far as I know, dot net can support AJAX functionality (which I believe was at the heart of everything).
The demos of the new site were very cool (apparently we paid someone a lot of money to design the site...a LOT of money). It looked all web 2.0ey, big buttons, small text (which is a suprise given we are an HMO managing Medicare). It looked a lot like the 37signals applications in fact. I guess I've read Tom Kyte for far too long and his rant about putting business logic in the database because the front end will always change. Seems true. Java or dot net were all the rage a few years back, now it's Ruby, in a couple of years it will be something else (ApEx!) at which point we will have to rewrite the whole thing.
Next up, MySQL. It's a given that this database has come a long way. Version 5 even has stored procedures. It's a great free database that supports many websites out there. Free is good. Well, mostly free anyway, we do pay support costs right now. Almost every new project is built on top of MySQL. Why? I'm not sure other than free.
I asked the question to the CIO in one of our All-Hands meetings and his response was cost.
Fair enough, Oracle is expensive. The way we use Oracle is even more so. Each project seems to get it's own database. Why they don't get a schema on an existing database I don't quite understand. I've been told that it is a logistical nightmare to pull down a database that affects so many different applications. Each group wants their own version, etc., etc.
I can understand the Data Warehouse having their own database and perhaps our main appplication having it's own database; but every single application? Why not a one off database that houses all the smaller applications in different schemas? That's what Oracle was built for? Plus you can reuse code, reduce the number of instances (thus reducing the cost)...I just don't understand.
I believe my main complaint is that they are still just treating the database (whether Oracle or MySQL) like a bucket. Web people should not be writing SQL; Ruby people should not be writing SQL; just like I shouldn't be writing Ruby code. I don't know it.
I would be willing to bet that I could re-create many of our smaller applications in a much shorter period of time in Oracle and ApEx given the same requirements.
So I rant on. If I truly thought that this was an effort to make IT cheaper and more sustainable, I would be on board. I just don't see that that is the case...
Labels: database, mysql, open source, oracle, work
¶ 1/27/2008 09:53:00 PM 6 Comments Links to this post
Saturday, January 26, 2008
Corporate LIfe (Continued)
The rumors were true, our top three executives resigned on Friday. I have a tendency to believe in the best of people so I sure hope this is their idea of taking one for the team.
If you're interested you can read more about it here, here, and here.
As prodlife mentioned in her comments from my previous post, layoffs are something (thankfully) I haven't had to endure. But it may come after the possible acquisition.
I don't think I'm too worried, jobs seem fairly easy to come by. I'd just like some stability for awhile.
If you're interested you can read more about it here, here, and here.
As prodlife mentioned in her comments from my previous post, layoffs are something (thankfully) I haven't had to endure. But it may come after the possible acquisition.
I don't think I'm too worried, jobs seem fairly easy to come by. I'd just like some stability for awhile.
Labels: work
¶ 1/26/2008 10:34:00 PM 0 Comments Links to this post
Wednesday, January 23, 2008
Corporate Life
One of the biggest reasons we decided to move down to Tampa (November 2006) was so that I can work in a "real" corporate environment (i.e. more than a few hundred people). WellCare has about 3,000 employees, IT makes up about 250.
It feels like I've experienced about every event I could have imagined:
1. In January of 2007, a new CIO/SVP was hired and promptly restructured (replaced the VPs) the IT department.
2. In October of 2007, we had a nifty FBI raid.
3. January of 2008, we appear to be losing our CEO, CFO and General Counsel.
Now I just need to wait for the merger/acquisition and I will have experienced just about everything! ¶ 1/23/2008 09:24:00 PM 1 Comments Links to this post
It feels like I've experienced about every event I could have imagined:
1. In January of 2007, a new CIO/SVP was hired and promptly restructured (replaced the VPs) the IT department.
2. In October of 2007, we had a nifty FBI raid.
3. January of 2008, we appear to be losing our CEO, CFO and General Counsel.
Now I just need to wait for the merger/acquisition and I will have experienced just about everything! ¶ 1/23/2008 09:24:00 PM 1 Comments Links to this post
Tuesday, January 8, 2008
Asynchronous Distributed HotLog - CDC Part III
This is the third installment (one and two)of my attempts to configure Oracle's CDC from a 9.2.0.6 source (highest release for windows) to a 10.2.0.1 (ditto) target.
After being appropriately set up with privileges (DBA's trusted me with the DBA role!) on our actual environments, 9.2.0.7 source and 10.2.0.3 target (Sun Solaris), I've moved back to trying to just get a simple proof of concept working on my machine.
That's had it's own difficulties, though I can safely say that I can manually create 9i and 10g databases manually.
Getting the databases configured properly has been my biggest challenge. I had eliminated most possibilities down to either Net Services or something to do with the JVM. I used my local listener and ruled out Net Services. It was down to the JVM. I kept getting this strange error:
Installing InterMedia was a pain. I kept getting a failure of a particular jar (ORA-23542?), could not resolve the class.
I googled one of the classes that failed to see if anyone had run across this before. There was only one record found...and it was mine from about a year and half ago! I found that very amusing.
So I went into the\ord\im directory and found a readme.txt. As I am scanning through it I see CLASSPATH. So I add the environment variable and voila! Perfect install. That would have solved my problem from before too. I followed the docs on the install to a T. Nothing in there about CLASSPATH. Perhaps I should write them and ask for it to be added?
Anyway, thinking the best, since I had a perfectly clean installation, I tried again:
At least the ORA-0600 is gone, but I am back to where I started.
Another good thing is that I am really learning how to pour through trace files and tkprof files.
All the examples I have found make it seem so easy...why can't I get this dang thing to work?!
After being appropriately set up with privileges (DBA's trusted me with the DBA role!) on our actual environments, 9.2.0.7 source and 10.2.0.3 target (Sun Solaris), I've moved back to trying to just get a simple proof of concept working on my machine.
That's had it's own difficulties, though I can safely say that I can manually create 9i and 10g databases manually.
Getting the databases configured properly has been my biggest challenge. I had eliminated most possibilities down to either Net Services or something to do with the JVM. I used my local listener and ruled out Net Services. It was down to the JVM. I kept getting this strange error:
A trace file was generated (with the above error) but it didn't really tell me anything. I googled the phrase, nothing. I went to Metalink, nothing. It looked like a Java call though, so I tore the database down and rebuilt everything. Just in case, I added XDB, Data Mining and InterMedia in case there was some reference there.
ERROR at line 1:
ORA-00600: internal error code, arguments: [qccsrc_createHLSource-3], [], [],
[], [], [], [], []
ORA-06512: at "SYS.DBMS_CDC_IPUBLISH", line 133
ORA-06512: at line 1
ORA-06512: at "SYS.DBMS_CDC_PUBLISH", line 226
ORA-06512: at line 2
Installing InterMedia was a pain. I kept getting a failure of a particular jar (ORA-23542?), could not resolve the class.
I googled one of the classes that failed to see if anyone had run across this before. There was only one record found...and it was mine from about a year and half ago! I found that very amusing.
So I went into the
Anyway, thinking the best, since I had a perfectly clean installation, I tried again:
And I waited for an agonizing minute thinking I had it this time...
SQL> BEGIN
2 dbms_cdc_publish.create_hotlog_change_source
3 ( change_source_name => 'T',
4 description => 'Test',
5 source_database => 'ORANINE' );
6 END;
7 /
Barnacles!
BEGIN
*
ERROR at line 1:
ORA-01426: numeric overflow
ORA-06512: at "SYS.DBMS_CDC_IPUBLISH", line 133
ORA-06512: at line 1
ORA-06512: at "SYS.DBMS_CDC_PUBLISH", line 226
ORA-06512: at line 2
At least the ORA-0600 is gone, but I am back to where I started.
Another good thing is that I am really learning how to pour through trace files and tkprof files.
All the examples I have found make it seem so easy...why can't I get this dang thing to work?!
Labels: cdc, dbms_cdc_publish, development, howto, work
¶ 1/08/2008 12:11:00 AM 0 Comments Links to this post
Wednesday, December 5, 2007
Instrumentation: DEBUG/LOGGING
In my previous entry on instrumenting code I detailed the way in which you could use the DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS procedure to help monitor your long running code.
In this one, I will detail my home grown version of Tom Kyte's debug routine. I do know that others have similar code but can't seem to find them right now.
You can find the source code here.
Contents:
2 tables
2 sequences
1 package
1 procedure
1 build file
debug_tab allows you to turn the debugging on and off. debug_details_tab will store each line that you write to the debug routine when turned on.
Here's an example of it in practice:
I mentioned in the previous article that I had had difficulty grasping this concept initially. I think once I related it to DBMS_OUTPUT.PUT_LINE it became much more clear to me.
This simple debug routine has helped me tremendously in the last year or two that I have used it. Especially when you get nested levels of logic. It gets very hard to keep track of where you are, but with this you can run your procedure or function and then issue a SELECT against the debug_details_tab and see what was happening when.
I even began using this in my APEX applications. I would preface each line with "APEX: " and then write whatever was necessary so that I could step through the various pieces of code. It became crucial when I was doing validation on a table of records in a collection...oh so much easier.
On large systems this will generate a lot of data. I definitely would not put this inside a loop doing some sort of batch processing, but it is helpful to find where things fail out.
It can certainly be improved on. I basically took the idea of DBMS_OUTPUT.PUT_LINE and wrote it to a table, nothing fancy there. Mr. Kyte mentions writing it to the file system as well. Since I don't have ready access to the database file system, this was the easiest.
Make your life easier and use a debug/logging routine in your code. No longer will you have to comment, the debug statements should do it for you!
In this one, I will detail my home grown version of Tom Kyte's debug routine. I do know that others have similar code but can't seem to find them right now.
You can find the source code here.
Contents:
2 tables
2 sequences
1 package
1 procedure
1 build file
debug_tab allows you to turn the debugging on and off. debug_details_tab will store each line that you write to the debug routine when turned on.
Here's an example of it in practice:
CREATE OR REPLACE
FUNCTION get_age_in_months( p_id IN NUMBER ) RETURN NUMBER
IS
l_age_in_months INTEGER;
BEGIN
--instrumentation calls
debug( 'GET_AGE_IN_MONTHS' );
debug( 'P_ID: ' || p_id );
debug( 'select value into variable' );
SELECT age_in_months
INTO l_age_in_months
FROM people_tab
WHERE id = p_id;
debug( 'L_AGE_IN_MONTHS: ' || l_age_in_months );
RETURN l_age_in_months;
EXCEPTION
WHEN no_data_found THEN
debug( 'no data found' );
RETURN NULL;
END get_age_in_months;
/
show errors
I mentioned in the previous article that I had had difficulty grasping this concept initially. I think once I related it to DBMS_OUTPUT.PUT_LINE it became much more clear to me.
This simple debug routine has helped me tremendously in the last year or two that I have used it. Especially when you get nested levels of logic. It gets very hard to keep track of where you are, but with this you can run your procedure or function and then issue a SELECT against the debug_details_tab and see what was happening when.
I even began using this in my APEX applications. I would preface each line with "APEX: " and then write whatever was necessary so that I could step through the various pieces of code. It became crucial when I was doing validation on a table of records in a collection...oh so much easier.
On large systems this will generate a lot of data. I definitely would not put this inside a loop doing some sort of batch processing, but it is helpful to find where things fail out.
It can certainly be improved on. I basically took the idea of DBMS_OUTPUT.PUT_LINE and wrote it to a table, nothing fancy there. Mr. Kyte mentions writing it to the file system as well. Since I don't have ready access to the database file system, this was the easiest.
Make your life easier and use a debug/logging routine in your code. No longer will you have to comment, the debug statements should do it for you!
Labels: code, development, howto, instrumentation, plsql, tools, utilities, work
¶ 12/05/2007 09:03:00 PM 1 Comments Links to this post
Sunday, December 2, 2007
Instrumentation: DBMS_APPLICATION_INFO
Instrumentation has something that I have come to rely on fairly heavily. I believe I first read about it on asktom, but the one that really spurred me on was this post on instrumentation on his personal blog.
Initially, I couldn't really wrap my head around instrumentation. I don't know why it was so difficult; I had a similar problem with sessions when I first started my career. I look back now and it just seems so obvious.
Now that I am doing datawarehouse work, nothing is fast. Fast to me is now one hour to load 30 or 40 million records. No more split second queries for me.
We currently use no tools. It's straight PL/SQL. Instrumentation of the code is ideal. Actually, it's more instrumentation to aid monitoring. The tool most easily used is provided by Oracle in the DBMS_APPLICATION_INFO package.
There are three subprograms that I use most, SET_MODULE, SET_ACTION and most importantly SET_SESSION_LONGOPS. I hadn't started using it until this year, I mainly stuck to the first two. SET_SESSION_LONGOPS is now part of my procedure/function template I've created in JDeveloper.
What it allows you to do is set a row in the v$session_longops view (I know it's not actually putting the row in the view...it's the underlying table, but I digress). You can then monitor how your job is doing.
Here's an example:
g_index and g_slno are global variables in the package. l_table is a PL/SQL TABLE OF VARCHAR2.
Now you can monitor the progress of your job in v$session_longops!
Here's the query I use:
Now you too can sit for hours and watch your job move incrementally forward!
But seriously, it does help tremendously to know where a job is at. You can further use the SET_MODULE and SET_ACTION calls to see a specific point in the processing (inside a loop).
Here's the code in context:
Initially, I couldn't really wrap my head around instrumentation. I don't know why it was so difficult; I had a similar problem with sessions when I first started my career. I look back now and it just seems so obvious.
Now that I am doing datawarehouse work, nothing is fast. Fast to me is now one hour to load 30 or 40 million records. No more split second queries for me.
We currently use no tools. It's straight PL/SQL. Instrumentation of the code is ideal. Actually, it's more instrumentation to aid monitoring. The tool most easily used is provided by Oracle in the DBMS_APPLICATION_INFO package.
There are three subprograms that I use most, SET_MODULE, SET_ACTION and most importantly SET_SESSION_LONGOPS. I hadn't started using it until this year, I mainly stuck to the first two. SET_SESSION_LONGOPS is now part of my procedure/function template I've created in JDeveloper.
What it allows you to do is set a row in the v$session_longops view (I know it's not actually putting the row in the view...it's the underlying table, but I digress). You can then monitor how your job is doing.
Here's an example:
dbms_application_info.set_session_longops
( rindex => g_index,
slno => g_slno,
op_name => 'GETTING MEMBER DATA',
sofar => 0,
totalwork => l_table.COUNT + 1,
target_desc => 'GETTING MEMBER DATA' );
g_index and g_slno are global variables in the package. l_table is a PL/SQL TABLE OF VARCHAR2.
Now you can monitor the progress of your job in v$session_longops!
Here's the query I use:
SELECT
username,
sid,
serial#,
TO_CHAR( start_time, 'MM/DD/YYYY HH24:MI:SS' ) start_ti,
time_remaining rem,
elapsed_seconds ela,
ROUND( ( sofar / REPLACE( totalwork, 0, 1 ) ) * 100, 2 ) per,
sofar,
totalwork work,
message,
target_desc
FROM v$session_longops
WHERE start_time >= SYSDATE - 1
ORDER BY start_time DESC
Now you too can sit for hours and watch your job move incrementally forward!
But seriously, it does help tremendously to know where a job is at. You can further use the SET_MODULE and SET_ACTION calls to see a specific point in the processing (inside a loop).
Here's the code in context:
PROCEDURE get_member_data
IS
l_exists INTEGER;
TYPE table_of_lobs IS TABLE OF VARCHAR2(3);
l_table TABLE_OF_LOBS := TABLE_OF_LOBS( 'COM', 'ORG' );
l_count INTEGER := 0;
BEGIN
--check to see if there is enrollment data, if not, move on
SELECT COUNT(*)
INTO l_exists
FROM members
WHERE rownum < 2;
IF l_exists = 1 THEN--data exists, truncate and reload
g_index := dbms_application_info.set_session_longops_nohint;
EXECUTE IMMEDIATE 'TRUNCATE TABLE member_stg';
g_audit_key := p_audit.begin_load
( p_targettable => 'MEMBER_STG',
p_loadsource => 'MEMBER_SOURCE',
p_loadstatus => 'PRE',
p_loadprogram => 'GET_MEMBER_DATA',
p_commenttext => 'INSERT' );
dbms_application_info.set_session_longops
( rindex => g_index,
slno => g_slno,
op_name => 'GETTING MEMBERS',
sofar => 0,
totalwork => l_table.COUNT + 1,
target_desc => 'GETTING MEMBERS' );
FOR i IN 1..l_table.COUNT LOOP
l_count := l_count + 1;
INSERT INTO member_stg
SELECT *
FROM members;
g_total_rows_affected := g_total_rows_affected + sql%rowcount;
COMMIT;
dbms_application_info.set_session_longops
( rindex => g_index,
slno => g_slno,
op_name => 'GETTING MEMBERS',
sofar => l_count,
totalwork => l_table.COUNT + 1,
target_desc => 'GETTING MEMBERS' );
END LOOP;
p_audit.end_load
( p_auditkey => g_audit_key,
p_loadstatus => 'SUC',
p_rowsuccess => g_total_rows_affected );
gather_table_stats
( p_tablename => 'MEMBER_STG',
p_schemaname => 'MYHOME' );
dbms_application_info.set_session_longops
( rindex => g_index,
slno => g_slno,
op_name => 'GETTING MEMBERS',
sofar => l_count + 1,
totalwork => l_table.COUNT + 1,
target_desc => 'GETTING MEMBERS' );
END IF;
EXCEPTION
WHEN others THEN
p_audit.failed_load
( p_auditkey => g_audit_key,
p_comments => SQLCODE || ' ' || SQLERRM );
RAISE;
END get_member_data;
Labels: dbms_application_info, development, instrumentation, plsql, sql, work
¶ 12/02/2007 10:04:00 PM 0 Comments Links to this post
Friday, November 30, 2007
Ling Chi II
or Death By a Thousand Cuts. I wrote about it before.
Today was one of the worst days I've had at this job.
I got home last night knowing I had to run and test a new line of business in our test environment. This was a fairly small subset so it should run fairly fast, two or three hours. Around 1:30 AM, it completed. I did my quick sanity checks and realized that it just wasn't working right.
Crap, I forgot to load our new rates. That has to be it.
So I reran the rates and then reran our process.
It's now 3:00 AM. I run my sanity check and it's exactly the same as the last one.
I quickly realize that some of the rates hadn't been updated like I assumed they had. This test was null and void. I went to sleep...mad.
I woke up around 8:15 with my son telling me something about Transformers. What? Oh, OK, I'm in his bed. I take him to school and get to work around 9:15.
I'm cranky because the other developer didn't do his part, but probably more mad at myself for not making sure they completed their piece.
I throw a piece of candy. Better.
Of course my colleague isn't in today, so I have to make sure the DBAs deploy this to our test environment.
Finally I get the process working and it finishes around noon. I send out a note to the business and QA letting them know that they can begin.
I get a call from the business around 2:30, it's not working the way they expected. One of our rates overlaps another causing invalid results to return.
Thanks for telling us that sooner. The day before deployment and were getting new requirements. Awesome!
I walk over to my boss' desk with my badge in hand, ready to quit, kind of, to tell him the news. He talks me off the ledge.
We then head over to their building to discuss and indeed it's something they didn't realize. OK, fair enough. Had they seemed to appreciate me/us a little bit more over the past eight months I probably wouldn't have been so mad. It was just one more thing though.
My boss decides how this will be remedied. I argue (gently) that this is not an application issue but a data issue. He agrees. We'll just put one job on hold and make the necessary changes to the [driving] data.
Two IT VPs, one business VP and the CIO need to sign off on two change requests, one for the driving data and one for the application.
We're slated to deploy tomorrow pending UAT signoff, though that shouldn't be a problem.
Ten to twenty percent of my time is spent writing code, the rest is paperwork. I believed I had mastered the administrative stuff only to get this requirement change at the last minute.
One more thing...just one more thing.
Ling Chi indeed.
Today was one of the worst days I've had at this job.
I got home last night knowing I had to run and test a new line of business in our test environment. This was a fairly small subset so it should run fairly fast, two or three hours. Around 1:30 AM, it completed. I did my quick sanity checks and realized that it just wasn't working right.
Crap, I forgot to load our new rates. That has to be it.
So I reran the rates and then reran our process.
It's now 3:00 AM. I run my sanity check and it's exactly the same as the last one.
I quickly realize that some of the rates hadn't been updated like I assumed they had. This test was null and void. I went to sleep...mad.
I woke up around 8:15 with my son telling me something about Transformers. What? Oh, OK, I'm in his bed. I take him to school and get to work around 9:15.
I'm cranky because the other developer didn't do his part, but probably more mad at myself for not making sure they completed their piece.
I throw a piece of candy. Better.
Of course my colleague isn't in today, so I have to make sure the DBAs deploy this to our test environment.
Finally I get the process working and it finishes around noon. I send out a note to the business and QA letting them know that they can begin.
I get a call from the business around 2:30, it's not working the way they expected. One of our rates overlaps another causing invalid results to return.
Thanks for telling us that sooner. The day before deployment and were getting new requirements. Awesome!
I walk over to my boss' desk with my badge in hand, ready to quit, kind of, to tell him the news. He talks me off the ledge.
We then head over to their building to discuss and indeed it's something they didn't realize. OK, fair enough. Had they seemed to appreciate me/us a little bit more over the past eight months I probably wouldn't have been so mad. It was just one more thing though.
My boss decides how this will be remedied. I argue (gently) that this is not an application issue but a data issue. He agrees. We'll just put one job on hold and make the necessary changes to the [driving] data.
Two IT VPs, one business VP and the CIO need to sign off on two change requests, one for the driving data and one for the application.
We're slated to deploy tomorrow pending UAT signoff, though that shouldn't be a problem.
Ten to twenty percent of my time is spent writing code, the rest is paperwork. I believed I had mastered the administrative stuff only to get this requirement change at the last minute.
One more thing...just one more thing.
Ling Chi indeed.
Labels: development, sql, work
¶ 11/30/2007 10:03:00 PM 0 Comments Links to this post
Thursday, November 29, 2007
Keeping it Simple
One of my all time favorite articles is The Complicator's Gloves on Worse Than Failure (formerly the DailyWTF). It identifies the tendency of software developers in particular to come up with overly complex solutions, usually when there is a much simpler one available.
This was the context of my latest rant to my CIO. Actually, this theme seems to play out in all my rants. Funny how that works.
While web services and the like have their place, many times they are used just because they are the cool new thing, not because of a pressing need. I know I am not the first to mention that nor will I be the last.
Whether it was years of reading asktom (for pleasure no less) or the influence of my first boss, I have striven (sp?) to build applications that are scalable yet easy to maintain.
One of my proudest accomplishments as a developer was at my previous job. A small state-contracted agency where I was the lone developer. I, thanks to a very trusting boss, was allowed to install Oracle and soon after found Application Express (APEX). In 18 months I was able to create some 350 pages of forms and reports for the organization. One person, 350 pages. I once found a job ad for a web developer to help maintain a 100 page website on a team of six. What? Six people? Really? Must be java or something. ;)
I continued to work for them on a contract basis for about six months after I left. Mostly until the new guy got comfortable. Unfortunately for me, they didn't require my services a whole lot. Yes, I could be deluding myself, I realize that...but I just don't believe it. They WOULD tell me.
Back to my point. At our organization we seem to have quite a few architects. They talk of Ruby on Rails, Java, JBoss, etc. MySQL gets a brief mention on occasion.
We have a hard enough time writing good SQL or PL/SQL, so now we're going to introduce new languages and a new database platform?
If we were a company that made software, I will probably be [mostly] on board, but we are not. We store and manage data for the business to do their job.
I do hope I am wrong about them and that they do talk about the importance of data in our organization. I just haven't see it yet.
So, put it in the database, use APEX when appropriate (95% of the time) and keep it simple.
This was the context of my latest rant to my CIO. Actually, this theme seems to play out in all my rants. Funny how that works.
While web services and the like have their place, many times they are used just because they are the cool new thing, not because of a pressing need. I know I am not the first to mention that nor will I be the last.
Whether it was years of reading asktom (for pleasure no less) or the influence of my first boss, I have striven (sp?) to build applications that are scalable yet easy to maintain.
One of my proudest accomplishments as a developer was at my previous job. A small state-contracted agency where I was the lone developer. I, thanks to a very trusting boss, was allowed to install Oracle and soon after found Application Express (APEX). In 18 months I was able to create some 350 pages of forms and reports for the organization. One person, 350 pages. I once found a job ad for a web developer to help maintain a 100 page website on a team of six. What? Six people? Really? Must be java or something. ;)
I continued to work for them on a contract basis for about six months after I left. Mostly until the new guy got comfortable. Unfortunately for me, they didn't require my services a whole lot. Yes, I could be deluding myself, I realize that...but I just don't believe it. They WOULD tell me.
Back to my point. At our organization we seem to have quite a few architects. They talk of Ruby on Rails, Java, JBoss, etc. MySQL gets a brief mention on occasion.
We have a hard enough time writing good SQL or PL/SQL, so now we're going to introduce new languages and a new database platform?
If we were a company that made software, I will probably be [mostly] on board, but we are not. We store and manage data for the business to do their job.
I do hope I am wrong about them and that they do talk about the importance of data in our organization. I just haven't see it yet.
So, put it in the database, use APEX when appropriate (95% of the time) and keep it simple.
Labels: apex, database, development, work
¶ 11/29/2007 01:00:00 AM 1 Comments Links to this post
Monday, November 26, 2007
Oops I've Done it Again
By it, I mean I've sent another rant to my CIO. Here's my first one that I sent to Dratz before starting my own blog.
Fortunately, we've developed a bit of a rapport. I still should not do this type of thing on a holiday when it could be days before I hear back...it just makes my mind wander and wonder if I will have a job come Monday.
I still have a job...I really need to stop this. ¶ 11/26/2007 12:42:00 AM 1 Comments Links to this post
Fortunately, we've developed a bit of a rapport. I still should not do this type of thing on a holiday when it could be days before I hear back...it just makes my mind wander and wonder if I will have a job come Monday.
Update
I still have a job...I really need to stop this. ¶ 11/26/2007 12:42:00 AM 1 Comments Links to this post
Tuesday, November 13, 2007
Death By a Thousand Cuts
In case I haven't mentioned it before, I work for a fairly immature IT organization. We're heading in the right direction mind you, but defined and documented processes don't really exist.
Yesterday I went back and forth with our QA department about two truncate table statements. We had performed this in production before and we didn't change the code. It needed to be tested and I needed to do a unit test plan. Today I needed UAT signoff. What? There's no business user.
Our EDI group is overtaxed right now, so I wrote a process to delete data in "their" database on tables that they created. Part of that process was to drop the constraints and then recreate them with the ON DELETE CASCADE rule. Amusingly, they created most of them with the SET NULL rule and then had NOT NULL constraints on those columms. Sweet. I needed to do all this and finally delete the data, of course none of the environments (DEV/TEST/PROD) are the same, so what worked in DEV didn't work in TEST. I'm guessing that as soon as it is deployed in PROD, I will have missed something else. I'll look like the idiot too. Did I mention that I have to create indexes for all those foreign keys? No, well, I did. Otherwise the process would take days to complete. There are some 13 tables in total. Three child tables of the parent table and then multiple child tables of those child tables. Awesome!
I'm on my fifth day of trying to complete a "simple" delete now.
Since the FBI raided, QA has become more strict. OK, understandable, but there was never a notice saying so, nor what the new rules would be.
I finally get my final approval and the work orders are created. Release Management gives me the all clear (the files were staged for the DBAs). I ran over to let them know and he wants to go through the instructions before I leave to make sure everythings clear. We then go into the s
Yesterday I went back and forth with our QA department about two truncate table statements. We had performed this in production before and we didn't change the code. It needed to be tested and I needed to do a unit test plan. Today I needed UAT signoff. What? There's no business user.
Our EDI group is overtaxed right now, so I wrote a process to delete data in "their" database on tables that they created. Part of that process was to drop the constraints and then recreate them with the ON DELETE CASCADE rule. Amusingly, they created most of them with the SET NULL rule and then had NOT NULL constraints on those columms. Sweet. I needed to do all this and finally delete the data, of course none of the environments (DEV/TEST/PROD) are the same, so what worked in DEV didn't work in TEST. I'm guessing that as soon as it is deployed in PROD, I will have missed something else. I'll look like the idiot too. Did I mention that I have to create indexes for all those foreign keys? No, well, I did. Otherwise the process would take days to complete. There are some 13 tables in total. Three child tables of the parent table and then multiple child tables of those child tables. Awesome!
I'm on my fifth day of trying to complete a "simple" delete now.
Since the FBI raided, QA has become more strict. OK, understandable, but there was never a notice saying so, nor what the new rules would be.
I finally get my final approval and the work orders are created. Release Management gives me the all clear (the files were staged for the DBAs). I ran over to let them know and he wants to go through the instructions before I leave to make sure everythings clear. We then go into the s