Ok, so for the last, I don't know... 20 years Oracle has been telling us to setup our environment to have a shared ORACLE_HOME between ASM and the RDBMS. When they introduced Grid and other new bells and whistles a couple of years ago they said that it was optional to use Grid which meant that it would be optional to create a 2nd ORACLE_HOME.
So I hit an internal Oracle error that can only be resolved by upgrading the database from 11.1 to 11.2. I think to myself "No big deal, I've upgraded many databases over the years.". So I upgrade the damn thing... what do you know... Grid is now required and forced down my throat as part of the 11.2 release. You do not have to use the Grid Infrastructure and management and I don't... they had the GENIUS idea of putting my ASM instance and binaries under the Grid home.
So what does this mean? I had to change my ORACLE_HOME for the RDBMS, no big deal. Then the server locks up and gets rebooted for some reason. When the server came back up it tried to use a single ORACLE_HOME (per the profile) to start ASM. Well ASM and sqlplus binaries are accessible via the RDBMS so it actually managed to start some false ghost instance using the RDBMS home. Now I'm totally confused and pissed off.
I can't just add both directories to the same ORACLE_HOME environment variable because they both have identically named binaries that are used for different things. The real solution to match Oracle Best Practices is to create a user that does nothing other than administer Grid and ASM and then setup that user with the Grid/ASM home and my ORACLE user with the RDBMS home.
In order to do this going forward we would have to make changes to every version of our cookie cutter OS builds to add a new user and profile. Then I would have to make changes to my own deployment so that everything played nicely out of the box. This would take at least a month. I can't believe these fuckers didn't think about this type of thing... just venting.
Oracle Venting
Re: Oracle Venting
Have you, and I am serious here, considered switching DBs? Or is that a management war you are unwilling to fight?
Grisbault, Twice-Made.
The p, s, l, and t are silent, the screams are not.
The p, s, l, and t are silent, the screams are not.
Re: Oracle Venting
No we have never considered it. Our need is scalability which is something that Oracle does phenomenally well. We would also need a report server and web server that plays nicely with it. Switching to a new database would also mean that we would have to recompile several hundred different reports for the new database/report server.
If moving over to the new database would be a smooth transition with minimal effort on me personally and it had the same performance when importing 10,000 ASCII records per day as when it imports 10,000,000 per day then I would be open to hearing what other solutions are out there.
If moving over to the new database would be a smooth transition with minimal effort on me personally and it had the same performance when importing 10,000 ASCII records per day as when it imports 10,000,000 per day then I would be open to hearing what other solutions are out there.
Re: Oracle Venting
10 000 000 isn't really that many - about 120 per second. But your legacy reports are the clincher.
Grisbault, Twice-Made.
The p, s, l, and t are silent, the screams are not.
The p, s, l, and t are silent, the screams are not.
Re: Oracle Venting
/dev/null for the WIN!