R.KU.PA_DBA (7/23/2016)
Drive for Binary files ..you can allocate 5 GB for it
Bear in mind this is per instance, if you're planning multiple instances per server then the binary drive size will need to reflect this
R.KU.PA_DBA (7/23/2016)
Drive for the Temp DB....40% of the X GB(Again it is also depend on the application uses....also you can have separate drive for Temp data file and Temp Log file)
This is not an exact science of specifying 40% pro rata and it really depends on the type of system you're deploying.
Specifically, usage of AlwaysOn availability groups with readable secondary's or usage of snapshot isolation or read committed isolation will generally push the TempDB required size.
R.KU.PA_DBA (7/23/2016)
After installation you should enable the DAC login on the system.
DAC is enabled by default, only on a clustered instance do you need to manually intervene.
Gavin Fuller (7/23/2016)
You will get slightly better performance from a physical server but given the advances in technology the different will be minor.
This is not completely true and I wouldn't be relying on this. Virtualisation has an overhead (10-15% should be allowed) and the more the host is over subscribed the worst things will get.
Gavin Fuller (7/23/2016)
I would however suggest keeping your data, logs and tempDB on separate physical drives.
In a Virtual Infrastructure this can be a futile exercise especially if your virtual disks are on the same datastore!
Also bear in mind, virtual disks do not handle random I\O too well. You can utilise Raw Device Mappings for the virtual disk but this makes the management harder for VI admins.
Gavin Fuller (7/23/2016)
The ideal would be to have as much memory as the total size of all data files but depending on the size and function of the databases this might not be realistic or overkill. However, be generous.
It's more realistic to provide the RAM size equivalent to the largest object in your largest database and allow an amount extra for proc cacahe, ext proc execution and CLR.
Your data file drive may be 1TB in size but your databases may only consume 600GB, you may have extra spare for index maintenance tasks, etc.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉