Wednesday, February 29, 2012

On Consulting

I've been thinking about this for quite some time now. 2+ years ago I joined a small, boutique consulting shop that focused on OBIEE. If you've been around her for any length of time, that 2+ years is a lifetime for me.

I've had the pleasure of meeting quite a few, very skilled, Oracle people over the last few years. I've shared beers with them and I've been able to pick their brain...a lot.

I ask questions, lots of them. Both my parents were journalists and boy did they ask a lot of questions. Wasn't the best thing, especially when I hit those teenage years (leave me alone!), but I can look back now and appreciate what they passed on to me.

I guess I'll go through my thoughts, pros and cons, of consulting. Fill in the blanks where necessary in the form of comments.

Cons

Let's start with the bad stuff, maybe that means you'll stick around to hear the good stuff below.
  1. Travel - This is both pro and con in my opinion. If you have a family, especially young children, travel is not fun. If you don't like to fly on airplanes, it's not fun. If you don't like living out of a suitcase, it's not fun. If you like coaching your son's baseball team, it's not fun. If you like having a schedule of any sort, it's not fun. I miss my family when I am gone.
  2. Food - Again, will be on both lists. If you try to watch what you eat, it's not easy to do while traveling. You have to work pretty hard to find good, healthy food while traveling. Sometimes it's just too easy to eat whatever is easiest. Heck, your tired from traveling, just make it easy. Easy <> Healthy.
  3. Exercise - It's incredibly tough to get into a groove when you travel a lot. You have to go out of your way, at times, to find either a decent running trail or decent gym equipment. Not easy.
  4. Benefits - No company provided health insurance. No time off. No sick days. If you aren't working, you aren't getting paid. If you suck at time management, like I do, this can be quite painful.
  5. The Hourly Wage - Pay is down there as a pro, as it should be. The part that I hate, is that if you aren't careful, you'll begin to think of all of your time as time you aren't billing. That ain't healthy. I think I've finally broken this mindset, but it wasn't easy.
Pros

Pros are easier.
  1. Pay - You get paid by the hour. I prefer this to the salaried positions...I would work upwards of 65 to 70 hours a week as a salaried employee. I'd end up making like $3 per hour. Blah. That sucks.
  2. Travel - If you like to travel, you'll get to do lots of it. I traveled a fair amount when I was a kid, I enjoy it (except the plane part, transporter technology needs to be invented soon). The first year with this consulting company included quite a bit of travel. I was a platinum member (75+ nights) at Marriott. I will be losing that status shortly as I have only traveled one time in the past 18 months for work.
  3. People - It should be no surprise that I like people. Well, with consulting, you get to meet a lot of new people from all over. I was a military brat, moved 8 times before I graduated high school, I really enjoy meeting new people.
  4. Problem Solving - I'll call this the AskTom effect. I have no doubt that Mr. Kyte was a pretty smart fellow prior to starting up that little site, but I think that forcing yourself to answer approximately 10 questions a day, has increased his breadth of knowledge by an order of magnitude. Granted, many of the questions he could probably answer of the top of his head, but...a big but, he constantly provides examples for those easy ones. And what about the hard ones? He answers those too. How often are you asked questions that test your knowledge limit in your particular area of expertise? He does that on a regular basis. I think the same goes for consulting, only on a smaller scale.

    Each and every client you go to has their own unique set of challenges. Things you wouldn't otherwise see if you stayed at one place your entire career. I believe you learn a lot more than the average person if you spend time in consulting simply because of those unique challenges.

    Here's another example. Cary Millsap estimates that he went to client sites about 35 times a year, for 10 years, during the 1990's. That's 350 different environments, different challenges all of them. Do you think that has had an impact on his knowledge and experience? I certainly do. I'll say the same thing about Mr. Millsap, he was a smart guy before doing all that, but I argue that it made him that much better at what he does/did.

    As does consulting in general.

    I've been through a few jobs in the past few years. Each job I learned something new. I was exposed to different problems. It made me better at what I did.

    The beauty of consulting, is that now I don't have to "change" jobs every now and then, I just get new clients. It is possibly one of the reasons I stayed in Gainesville, FL for so long, I got to stay in one place but everyone else came and went (it's a college town for those that don't know, a very transient population).
So, in summary, I really love the problem solving aspects of travel. Being paid for the time you actually work is a bonus, but there are trade-offs. I'm not sure I'll do this forever...I think it would be awesome to be at a job for years on end where you know everything about the business. I just don't see that in my very near future.

Monday, January 23, 2012

OBIEE 11g: Where's the Compare Repositories Dialog?

Recently I decided to try out the new patching capabilities for the metadata in OBIEE 11g. The big reason for me was to avoid having to reset my connection pools. Each time I did a 3 way merge, the connection pools would get over-written with their development credentials. When I was doing the merge, I could never find a way to isolate (leave out) those objects, so it was off to try the patching.

What this patching does is creates an xml file of the differences between 2 RPDs. You can then edit that XML file if you so desire. Most of my duties over the last couple of years have centered around the RPD and front-end stuff, not nearly as much on the administrative side (i.e. migrations). So I need to catch up with the rest of the world.

Reading through the docs, I'm told that I need to use the "Compare repositories" dialog. OK, easy enough.



Where is my entry for it?

OK, let's try the Compare entry.



Since I'm using the prod_20120122 RPD, I select the dev_20120122 RPD.

I'm prompted for the Repository Password and then it spins for a few seconds, then gives me this



I select Yes.



OK...where's the Compare Repositories Dialog like the docs say?

I see the icons have changed signifying differences, but no dialog as mentioned in the docs.

What if I select No?



Ah, there it is.

Interestingly, if I maximize that Compare Repositories Dialog, the next time I run the Compare, I can see it plain as day.



Hopefully you'll find this next time you endeavor to learn how to patch your RPD and can't seem to find the Compare Repositories Dialog.

Thursday, December 15, 2011

Trace Data: Not Just For DBAs

On Wednesday, I attended Cary Millsap's Mastering Oracle Trace Data class here in Tampa.

Why?

Why would I go? I am working with OBIEE which is about 42 layers above the database...who cares about trace data? Well, performance is usually the number 1 item on everyone's list. Page loads to slow. Report takes to long to run. Whether it's trying to tune the application server (WLS) or figure out why Report A takes so long to run, we do a lot of performance analysis. In most cases, it ends up being the SQL that is run. What I mean by the SQL is that it's usually bringing back quite a few records. I've seen people try to pull back millions of records and then pivot all that data putting a nice load on the BI Server and hogging all the resources from everyone else.

On occasion though, there are other things that are going on (with the SQL) that we can't pinpoint.

Recently we had to back out a production implementation because one of the load processes seemed to just hang, threatening to slow down a larger process.

I asked the DBAs why.

Crickets.

Shouldn't that be an answer a DBA provides?

Disk? Network? CPU? Memory? Which one?

Crickets. (I didn't ask those exact questions, I think I said, "Reads? Writes? Network? Load?")

That is just one of the reasons I wanted to attend Mr. Millsap's class. That, and I've heard he's well regarded and does a pretty decent job presenting. OK, I admit it, I just want to show the DBA up. There, said it.

I really shouldn't have to though. It's supposed to be a partnership. They don't know much about OBIEE, so I help them there. I expect help in things like this.

Why? Part II

If you are a developer, understanding trace data will make you better. You'll no longer have to guess, you'll know.

Of course there's what I hinted at above, being able to go to your DBA(s) and prove something. No better feeling in the world.

How?

MR Trace is by far the easiest. It's integrated with SQL Developer. It's a great place to start.

MR Tools - For the more advanced professional. Mostly geared towards the DBA type, but incredibly useful to developers as well. It includes:

- mrskew - your trace file profiler and data miner
- mrls: your trace file lister
- mrcallrm: your trace file correction fluid
- mrtrim: your trace file tim calculator
- mrtrimfix: your trace file time value fixer

Method R Profiler:
The classic tool that started it all, the Method R Profiler is software that makes simple work of knowing exactly why your application consumes the response time it does. With minimal training, a Method R Profiler user can—in just minutes—identify the root cause of an Oracle-based application performance problem, propose sensible solutions to it, and predict the end-user response time impact of each proposed solution.

There are of course other products, check them out here.

Ask Mr. Millsap to come to your town. Try out MR Trace. You won't be sorry you did.

Tuesday, October 18, 2011

KScope + DevOps

Last year I had the pleasure of getting the Sunday Symposium together for KScope 11, this year, I have completed my takeover of the Database track by becoming the track lead.

I thought this was the best job ever, then I was attacked Nancy Kerrigan style by my handlers.

All that said, I think I've gathered a pretty good group of people to help review and select the abstracts for next year's conference (San Antonio, TX).

There will be 4 sub-tracks this year:
- Design/Data Modeling
- Maintenance (Performance, Tuning, Upgrades)
- MySQL
- (Dev)Operations

The one I am most excited about is the (Dev)Operations sub-track, aka, DevOps.

What is DevOps?

I'm glad you asked..

"DevOps" is an emerging set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals.[1] It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization's goal of rapidly producing software products and services.

I am not necessarily a fan of the movement, but I am a fan of the principles behind it.

Every developer has a story about working with an evil DBA. LIkewise, every DBA has a story about some application that went to production where they were left completely out of the process.

But it is more than just a simple, "Can't we all just get along?" plea, this is about creating better software and streamlining processes.

My personal experience has been one of woeful cooperation, at any level. Our thought, our hope, is that this well help give other Oracle professionals better ideas on how to start down this road.

If you are interested in this topic, sign up. If you want to present on this (or any other) topic, register here.