The other day I told the story of how Christian Berg went out of his way to give me some invaluable pointers, OBIEE: How to Migrate Your rpd.
Apparently I haven't been the only one putting pressure on him to share his knowledge because he started his blog yesterday. So take a stroll over to his site and welcome him, then add him to your feed reader of choice.
Saturday, March 28, 2009
Friday, March 27, 2009
Thursday, March 26, 2009
Who's Your DBA?
I'm a "kind of" DBA, but not the real deal (yet). I do things from the application perspective which all you real DBAs laugh at (stop it).
I like competition, it's good for the soul. I've begun wondering who the best DBA in the world would be. As far as I know, there is no such competition.
A good place to start though would be the Oracle Certified Masters. Based on the curriculum to achieve said credential, I'd say these people would rank among the best right?
What about those that choose not to take it, but are more than worthy? Would it be those that blog? How could I ever know? (No Howard, it doesn't really matter, it's just curiousity).
Anyway, my DBA got mentioned by one of the better known DBAs out there, Tanel Poder. I'd say that's pretty cool.
Miladin Modrakovic is his name, Oraclue is his game. (Corny, I know).
Joking aside, I like (love?) working with this guy. If there is something I don't understand I can pass it along without fear of him not knowing. That hasn't always been my experience. My first "DBA" gig I was the only one there...I knew everything, or had to. It's such a relief to know that I don't have to know everything.
So if you like that real DBA stuff, internals, diagnostics, etc., check out his site. It's well worth the read.
I like competition, it's good for the soul. I've begun wondering who the best DBA in the world would be. As far as I know, there is no such competition.
A good place to start though would be the Oracle Certified Masters. Based on the curriculum to achieve said credential, I'd say these people would rank among the best right?
What about those that choose not to take it, but are more than worthy? Would it be those that blog? How could I ever know? (No Howard, it doesn't really matter, it's just curiousity).
Anyway, my DBA got mentioned by one of the better known DBAs out there, Tanel Poder. I'd say that's pretty cool.
Miladin Modrakovic is his name, Oraclue is his game. (Corny, I know).
Joking aside, I like (love?) working with this guy. If there is something I don't understand I can pass it along without fear of him not knowing. That hasn't always been my experience. My first "DBA" gig I was the only one there...I knew everything, or had to. It's such a relief to know that I don't have to know everything.
So if you like that real DBA stuff, internals, diagnostics, etc., check out his site. It's well worth the read.
Wednesday, March 25, 2009
OBIEE: How to Migrate Your rpd
None, absolutely none of the following is anything I produced.
Again, Twitter to the rescue.
Who is Christian Berg? Well, to me, he's the guy who commented on my first OBIEE post. We corresponded back and forth via email. After that and I believe I convinced him to join twitter. He was very helpful in his emails to me, pointing me in the right direction and so on.
Anyway, shortly after my last tweet above, I received an email from Christian. It was a detailed explanation of the different ways that you could migrate your rpd file, or what you have in development/qa to production.
So, with permission, I'll reprint the email here (by the way, people need to pressure him to blog, I don't want to have to keep giving him credit here ;).
Christian Berg
1.) You have a full multi-user development environment which allows you to group your rpd objects in "Projects" and use a check-in/check-out mechanism against a central repository. I.e. there's the central rpd on the server, you check out a project, make your changes and check it back in to the server. [ link ]
2.) You merge your local repository with the production repository. This one you knew probably and can't use it since your local repository contains more changes than you actually want to transfer. So here's a little trick: strip your local rpd down to the bare minimum of changes you want to propagate. This way all the merge will do is an upsert and shove all your new objects into the central rpd. [ link ]
3.) You can use "Import from archive". It's been deprecated and inactivated by Oracle in order to push people to usethe "merge" functionality. However, it's still alive and kicking in the background. It's a nice feature if you know exactly what you want to transfer and if what you want to transfer is really "encapsulated". I.e. you don't start shooting into generic business models or stuff like that but have all in nice purpose-built objects which are added on top existing ones. Since - as far as "updating" goes - the import is the most brutal one. [ link ]
There you have it. I would encourage all of you to do the following:
1. Let Christian know that he needs to start/resume his blog.
2. Give him lots of money by way of jobs or bonuses. He is most deserving.
Again, Twitter to the rescue.
 |
 |
 |
Who is Christian Berg? Well, to me, he's the guy who commented on my first OBIEE post. We corresponded back and forth via email. After that and I believe I convinced him to join twitter. He was very helpful in his emails to me, pointing me in the right direction and so on.
Anyway, shortly after my last tweet above, I received an email from Christian. It was a detailed explanation of the different ways that you could migrate your rpd file, or what you have in development/qa to production.
So, with permission, I'll reprint the email here (by the way, people need to pressure him to blog, I don't want to have to keep giving him credit here ;).
Christian Berg
1.) You have a full multi-user development environment which allows you to group your rpd objects in "Projects" and use a check-in/check-out mechanism against a central repository. I.e. there's the central rpd on the server, you check out a project, make your changes and check it back in to the server. [ link ]
2.) You merge your local repository with the production repository. This one you knew probably and can't use it since your local repository contains more changes than you actually want to transfer. So here's a little trick: strip your local rpd down to the bare minimum of changes you want to propagate. This way all the merge will do is an upsert and shove all your new objects into the central rpd. [ link ]
3.) You can use "Import from archive". It's been deprecated and inactivated by Oracle in order to push people to usethe "merge" functionality. However, it's still alive and kicking in the background. It's a nice feature if you know exactly what you want to transfer and if what you want to transfer is really "encapsulated". I.e. you don't start shooting into generic business models or stuff like that but have all in nice purpose-built objects which are added on top existing ones. Since - as far as "updating" goes - the import is the most brutal one. [ link ]
There you have it. I would encourage all of you to do the following:
1. Let Christian know that he needs to start/resume his blog.
2. Give him lots of money by way of jobs or bonuses. He is most deserving.
Subscribe to:
Posts (Atom)