I always thought that default configuration should be the simplest and the easiest for implementation, well until I met Oracle default configurations.
A good demonstration of this will be describing two projects I worked on in the past year.
Some background before I begin. We've decided in our organization it's time to implement SSO for the EBS. Now, we already had the OID infrastructure required with an operable SSO configuration. It was, however, decided I should migrate the single OID server to two Load-Balanced OID servers, for High Availability purposes of course. So, first phase I migrate to Load Balanced OID servers, second phase I make the necessary EBS adjustments.
I was amazed in both phases with how much sorting out I needed to do to understand what I really need to implement.
The only documentation to work with to migrate to a Load Balanced OID layer is the documentation which shows how to migrate to a totally High-Availability configuration in each layer, so after printing out all the documentation, I had to get rid of all the RAC and such related parts and even after that there were many parts I didn't really need for the final migration procedure.
The documentation about migrating to SSO for the EBS is even more ambitious, for some reason it's assumed that the second I implement SSO I'll implement full synchronization between the EBS and the OID (probably involving the master source of identities as well). What's wrong with just using the Kerberos Ticket users get from Windows for EBS authentication? At least for beginners? In a TAR I've opened to solve some related issue I had real hard time explaining that I have no reason for registering OID since I don't want any synchronization. Actually, since it appears as such a trivial step in the installation process I had my own share of doubts on this point.
My real question is why every paper assumes I'm on RAC (although it WILL happen one of these days, probably)? What's wrong with describing basic configurations and supplying pointers to the more advanced options?
1 comment:
I think that like everything else in the industry, the reason for talking about RAC everywhere, is financial. That is, Oracle wants you to upgrade your database to RAC, so they can charge more money, make you use more support and also make you brag about your RAC installation in your blog (good advertisment). Of course, no one will ever admit that, and the only thing you'll hear is "we recommand RAC, coz it makes your environment more resilient...". The default are good for Oracle's demos in their conferences, and rarely for your day-to-day usage.
Post a Comment