December 31, 2009 at 12:35 am
Comments posted to this topic are about the item Pre Check List for 64 BIT SQL Server 2008 Cluster Installation
Rudy
December 31, 2009 at 6:34 am
Just a quick question on your comment
"This virtual NIC is not liked by the SQL Server installation, which will complain and fail. You will need to "unteam" the NICs via the HP software and then you can disable or assign another IP address to them."
I keep reading about this issue over and over on the blogs but have been running virtual nics for years with my cluster. What sort of problems does SQL Server have with this setup so that I can watch out for it or not use when we rebuild our next one?
Thanks
Harold
December 31, 2009 at 6:46 am
Hello,
Good question and I too had asked that during my first install. Basically it comes down to NIC(s) that are not used. If there is a NIC installed (virtual or physical) and it is not used (configured and in use) then the installation will have a problem.
It appears that the Windows 2008 does not understand why you would have a NIC(s) that is installed but not in use.
Finally, if you are using a "teamed" configuration (a second NIC to handle a failure of the first NIC) then you are recommended to "unteam" then. Once your install is completed you can "re team" them.
Hope this helps,
Rudy
Rudy
December 31, 2009 at 7:15 am
Another issue that is somewhat related to this is installing on Server 2008 R2, which requires the installation to be slipstreamed. Its best to check before running the installation. http://support.microsoft.com/kb/955725
Curtis Smith
SQL Server DBA
Well in worked in Theory ...
December 31, 2009 at 9:31 am
We have teamed NIC's on just about all of our clusters where I work, and I personally haven't experienced any problems leaving them teamed for the SQL install. I've only done one Server 2008 R2 cluster install, but had no issues with the install, and connectivity is fine. The one issue we did find was a DNS message, but that was coming up because we manage our DNS system with QIP, and there is a fix from MS posted to prevent that message from appearing. Unfortunately, I can't locate the article... and I forget the exact message, but it was unrelated to having the NIC's teamed.
Great article though!!
Regards,
Steve
December 31, 2009 at 9:35 am
Thanks for the additional info. Looks like SQL 2008R2 has fixed this issue but it does exist with SQL 2008. I have not installed SQL 2008 R2 as that's for another article.
Thanks again,
Rudy
Rudy
December 31, 2009 at 9:54 am
Nice article
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
December 31, 2009 at 10:15 am
Thanks for all the great info and the replys.
January 4, 2010 at 3:15 am
I think this is a very helpful article. There is one aspect that many people take for granted, but I think should get challenged more, even if the challenge can be contentious...
I have seen advice from some tuning experts that turning off paging on a 64-bit machine can be best for performance. This is achieved by specifying a custom page file size of zero MB.
If you do this you will not get a system dump if Windows fails. Therefore you need to balance the risk of this with the inconvenience of making a page file available if you have a failure that needs a memory dump.
The advice from NT4 days that the page file shold be 1.5 time the size of physical memory is now obsolete. The 1.5 ratio is only needed if you want to dump all memory on the box. If you have a 128GB box, then Microsoft will never need a 192 GB dump to disgnose the problem you have, so why set your page file to 192 GB? If you do decide to have a 192 GB page file, you also need to work out how you will get a 192 GB dump to Microsoft.
IMHO that optimum size page file for a 64-bit box is zero MB, and the maximum size is the whatever is needed for a snap dump (400MB for W2008 R2).
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
January 4, 2010 at 10:12 am
Good article, as it addresses many issues with a WIn2008 and SQL2008 cluster on the install.
But no antivirus? You need to tune the antivirus correctly for a SQL system but to recommend no AV makes no sense at all. Are you going to scan your system every day? With no AV, you better be scanning it.
January 4, 2010 at 10:41 am
Thanks for the comment. We do a full scan from another server to our cluster. This AV server will scan all the hard drives attached and is set to skip over the database related files like .MDF, .LDF, etc.
By having this setup, there are no performance hit caused by the AV. If you have your cluster facing the internet for a website then maybe I can see the need. Our servers have been setup so that only the Domain Administrators can connect to the server and/or its drives. All users can only access the data within the databases and nothing more.
Thanks,
Rudy
Rudy
January 4, 2010 at 10:45 am
Ok. I work in a University environment. Our stuff is behind a firewall but certain ports need to be open from external websites to the SQL systems.
I cannot live without some type of real time antivirus solution or we pay the price. We basically do the same thing with file exclusions on real-time protection.
April 9, 2010 at 12:28 pm
Your method for defining the pagefile is incorrect and the other poster recommending 0MB pagefile is wrong too. The system's RAM needs PF space to write out old or infrequently used pages in memory. By disabling the PF you prevent this from happening. You also don't want to "fill your disk" with PF space. It should be set to 1.5 times your RAM amount. This was best practice in '95 and still is today. Better yet set it to systemed managed and forget about it.
April 12, 2010 at 4:35 am
It should be set to 1.5 times your RAM amount. This was best practice in '95 and still is today. Better yet set it to system managed and forget about it.
If you are running a 32-bit desktop environment with a small amount of memory this advice may make sense. If you are running a 64-bit machine dedicated to SQL Server and have more than (say) 4GB RAM then this advice wastes resources.
If you are worried about keping a specific size pagefile so you can get a memory dump, two things to consider:
1) Think about how often you get a repeatable system crash and how much time you want to wait while a dump file is written. Also think about how you will export the dump file to Microsoft. If you decide you will never give Microsoft a 48GB dump file then you have no justification for a 48GB pagefile.
2) Look at http://blogs.msdn.com/ntdebugging/archive/2010/04/02/how-to-use-the-dedicateddumpfile-registry-value-to-overcome-space-limitations-on-the-system-drive-when-capturing-a-system-memory-dump.aspx if you are running W2008 or above.
Mike Russinovich has a good blog about setting Windows memory use, see http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx. Read all of it but look out for the section about pagefile size. I have also seen advice from PSS engineers (but cannot find it now) about the specific situation of using a zero size pagefile.
FWIW, my machine at home has 12GB RAM with W2008 R2 as the main OS running Hyper-V. I run the host and all my guests with zero pagefile and have no crashes or hangs. The guests all seem to run faster than before I made this change, but I have not done tests to quantify this.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
April 12, 2010 at 8:43 am
Thanks EdVassie for the information and links regarding memory.
It seems to me that this is an area the needs to be looked at a system by systems basis. Not all setting in one company (or server) can be used by other companies or even other servers within the same company.
Just goes to show that a DBA's work is never done.
Rudy
Rudy
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply