RE: Oracle RAC on Win vs. Oracle on Linux

From: Goulet, Richard <Richard.Goulet_at_parexel.com>
Date: Tue, 23 Feb 2010 10:24:26 -0500
Message-ID: <6B0D50B70F12BD41B5A67F14F5AA887F047F6C0C_at_us-bos-mx022.na.pxl.int>



AH, I see we've sparked another HOLY WAR, bout time.  

    Well for one the Windows systems that we have around here are getting on in age. Yes they are Win2K and yes they are 32 bit because that's the way they were built by our wonderful friends at Dell. They also predate all of us in the department with a lot of history on how & why they were set up lost to the ether. Yes their running RAC, but that's about where it ends. There is no CRS or ASM running and believe it or not you can actually see the datafiles on the san. Really weird to say the least. There are 7 instances on each server & with only 16GB total memory they have been struggling since I signed on. Also why they were built as RAC system has been lost to the ether as well. The best we can get from memories is that Dell recommended it to preclude database unavaibility in the event of hardware failure (these machines have only 1 power supply). We're nearing the end of migrating them off of RAC and Windowze onto Linux and single node, single instance.  

Dick Goulet
Senior Oracle DBA/NA Team Lead
PAREXEL International  


From: Niall Litchfield [mailto:niall.litchfield_at_gmail.com] Sent: Tuesday, February 23, 2010 4:12 AM To: Goulet, Richard
Cc: rafiq9857_at_hotmail.com; Robert Freeman; oracle list Subject: Re: Oracle RAC on Win vs. Oracle on Linux

Hi Dick,  

First of all let me say that none of what follows is intended as a slight on either the decision you describe below which is perfectly fair and reasonable, nor the skills and competence of your wider team about which I know nothing. I'm really just using your post as a jumping off point to remake some of my argument in the new Oak Table press book and to comment on more general practice in the industry.  

The points you make (apart from the "blue screen of death") apply to 32bit Oracle on Windows. Strictly of course they also apply to 64bit Oracle on 64bit windows and when 8Tb of memory becomes a limiting factor for our databases then the same problems will apply there as well, this day is a way off - I'm hoping past my retirement but I doubt it, I expect to be seeing 128bit computing (and 64bit shops busy windowing into a 128bit address space in a mad attempt to avoid just using the right hardware and software in the first place then). 32bit windows is limited by the architecture to a relatively few number of concurrent sessions ( low hundreds typically) and to relatively low memory requirements as you describe -- and because each new connection uses 1mb of memory by default whether it's doing anything or not these two restrictions have become rather limiting <rant> especially as web developers can't close connections reliable when not needed</rant>.  

The proper solution here is not necessarily to jump ship to *nix, though that might be a perfectly reasonable decision for other reasons, but simply to move to 64bit computing of whatever flavour. After all it's extremely likely that your server and os have been running on 64bit hardware for some years now. What I do see often that really annoys me, though again I'm not suggesting this is your specific suggestion, is that *nix 64bit - especially Linux x86-64 - is superior to win32 because of the process and memory limits of the latter. Well doh! It is true that in a limited environment because of the process vs thread architecture Linux x86 is superior to win32 but then I'd be amazed if people were installing 32bit Linux either for much of the same reasons. It really isn't the 90s any more.  

If you really mean that you have an actual blue screen of death that frequently, it really ought to be resolvable and certainly shouldn't have anything to do with Oracle itself since this is caused (primarily) by kernel address space bugs in drivers or other kernel mode software (so I guess crs could cause a BSOD). Your expectation should be that a BSOD should never be seen on a server running windows 2003 or later and rarely on windows 2000 and that any such occurrence should result in a support ticket with either or both of the hardware vendor and/or microsoft themselves.  

Robert's original question was about RAC. I'd go back here to the comments in the other thread about RAC beng more complex and prone to human error than vanilla Oracle, and add that because of the clusterware and internetworking requirements it presents much more of an o/s management challenge than a vanilla o/s install, for that reason primarily I'd agree with the other posters who have commented upon where the skills of the system administration staff lie. Windows RAC in the hands of a Solaris SA is likely to be a disaster as is the reverse case.     

On Tue, Feb 23, 2010 at 2:02 AM, Goulet, Richard <Richard.Goulet_at_parexel.com> wrote:

        Rafiq,          

            As I'm working in one of the premier (top 10) trials companies to the pharma community we are moving all our databases/applications off of Windows for Unix based operating systems. These are validated, no problem. Windows has two basic problems, memory and processes. Without a start up switch your limited to 3GB total memory for Oracle, with the switch you can have another gb, but it uses memory context switches which are a performance killer. The second is that Oracle on Windows is multithreaded within a single executable where as Unix based systems have multiple processes again limiting capacity. Our windows based databases are a real pain in the shorts, they are constantly hitting that "blue screen of death" at least once a week. As it is after 1 June we will no longer support or validate a Windows database.          

	Dick Goulet 
	Senior Oracle DBA/NA Team Lead 
	PAREXEL International 

	 


________________________________
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mohammad Rafiq Sent: Monday, February 22, 2010 8:50 PM To: Robert Freeman; oracle list Subject: RE: Oracle RAC on Win vs. Oracle on Linux Robert, I don't agree that Window is evil. I seen problems with Windows
NT (mostly memory leak related) but after handling Oracle databases on Windows 2000 or newer version, it is quite stable. However it depends on SA of Windows server how competent they are to configure and handle Windows server.          

        I am mostly supporting Oracle databases of various versions on HP, RedHat Linux and Windows and did not find serious issues with Windows 2000+ servers. Although it is not a preferred environment but due vendor requirements for their application (specially for pharmceutical industry which needs validated application/databases) we need to put Oracle databases on Windows 2000/2003 servers.          

	Regards
	Rafiq
	 
	 
	

________________________________
Date: Mon, 22 Feb 2010 15:05:10 -0800 From: robertgfreeman_at_yahoo.com Subject: Oracle RAC on Win vs. Oracle on Linux To: oracle-l_at_freelists.org Anyone want to jump in on their preferred platform for RAC?
Personally I tend to lean towards Linux for stability purposes, but I'd like your thoughts on why you prefer either platform for RAC. Specifically why would you avoid windows (other than the fact that it's evil), or would you?         

        RF                            

	Robert G. Freeman
	Master Principle Consultant, Oracle Corporation
	Oracle ACE
	Author:
	Oracle Database 11g RMAN Backup and Recovery (Oracle Press) - ON
ITS WAY SOON!
	OCP: Oracle Database 11g Administrator Certified Professional
Study Guide (Sybex)
	Oracle Database 11g New Features (Oracle Press)
	Oracle Database 10g New Features (Oracle Press)
	Other various titles
	Blog: http://robertgfreeman.blogspot.com
<http://robertgfreeman.blogspot.com/>

        Hotmail: Powerful Free email with security by Microsoft. Get it now. <http://clk.atdmt.com/GBL/go/201469230/direct/01/>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info


--
http://www.freelists.org/webpage/oracle-l
Received on Tue Feb 23 2010 - 09:24:26 CST

Original text of this message