![]() | |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
First, RDBMS based http and OEM will not work without SCAN address on a RAC db. Second, with the requirement to put SCAN into DNS, DBA can no longer install RAC without any help, the person who maintains the DNS server, usually not DBA, will need to configure it. I am not aware that anybody was requesting SCAN address, it's a convenience, an endpoint for programmers to tie their services to, not something that would help the user. Making a mess of the installation and and making the SCAN address mandatory is infuriating, especially when having in mind that this is done so it's safer to use cheap Elbonian programmers. That is the reason for adding an additional level of complexity to otherwise already convoluted, buggy and complex RAC installation. In 10g, RAC installation became a form of black art. In 11g Oracle Corp. added more complexity to already convoluted and complex environment, with even less real documentation. The real question is whether this complexity has paid off? What did RAC 10g and RAC 11g provide that RAC 9i couldn't have provided? The answer is ASM. The real purpose of ASM is to block the competition. Competitors can and will use OCFS but competitors cannot use ASM. Thus the complexity. Now, we got SCAN address requirement, which is infuriating. I didn't even mention the idiotic multicast flop, which belongs to the same category. |
#3
| |||
| |||
|
|
On Sun, 07 Aug 2011 08:38:26 +0000, Mladen Gogala wrote: First, RDBMS based http and OEM will not work without SCAN address on a RAC db. Second, with the requirement to put SCAN into DNS, DBA can no longer install RAC without any help, the person who maintains the DNS server, usually not DBA, will need to configure it. I am not aware that anybody was requesting SCAN address, it's a convenience, an endpoint for programmers to tie their services to, not something that would help the user. Making a mess of the installation and and making the SCAN address mandatory is infuriating, especially when having in mind that this is done so it's safer to use cheap Elbonian programmers. That is the reason for adding an additional level of complexity to otherwise already convoluted, buggy and complex RAC installation. In 10g, *RAC installation became a form of black art. In 11g Oracle Corp. added more complexity to already convoluted and complex environment, with even less real documentation. The real question is whether this complexity has paid off? What did RAC 10g and RAC 11g provide that RAC 9i couldn't have provided? The answer is ASM. The real purpose of ASM is to block the competition. Competitors can and will use OCFS but competitors cannot use ASM. Thus the complexity. Now, we got SCAN address requirement, which is infuriating. I didn't even mention the idiotic multicast flop, which belongs to the same category. I tried redirecting it with DBMS_XDB.SETLISTENERENDPOINT to VIP hostname, but to no avail. It still didn't register with the listener. My conclusion is that SCAN is being rammed down our throats. I will hack around it. --http://mgogala.byethost5.com |
#4
| |||
| |||
|
|
you do know that you don't NEED SCAN, right? you can still start the default listeners, the same way as before. |
#5
| |||
| |||
|
|
as for the "infuriating" , have you not heard of DBA2.0. *If you are not a DBA 2.0, you need to work in that direction. *DBA2.0 is a SYS/ NET/SAN/DB Admin all rolled into one... Not to mention that being a DBA2.0, you really start to understand the "system" not just our little world of databases. |
![]() |
| Thread Tools | |
| Display Modes | |
| |