The only other thing to keep in mind with a consolidated SQL environment is conflcting SLAs between DBs. Your maintenance windows could be impacted as you'll most likely have to adhere to the strictest SLA.
- Sean On Mon, Aug 12, 2013 at 12:12 PM, Ziots, Edward <[email protected]> wrote: > Honestly, **** > > ** ** > > There is at least two realms of thinking on this. **** > > ** ** > > One: If the databases that are running on your physical servers are not > seriously IOPS heavy you might be able to get away with Virtualizing them > with the appropriate DISK on the virtual backend (Usually very fast SAS or > Flash drives). A lot of times, this may not scale well especially when > your data requirements ( both database size and IOPS and processing power > are going to be high). **** > > ** ** > > Two: Scale down the number of your SQL instances into HA clusters and then > look at SQL Mirroring, or Replication for your data availability needs. > (Looking at less licenses of SQL, and better manageability from a DBA > prespective) (only down side is increased administration and segregation of > loads on the SQL systems is needed along with making sure all DB’s and > there applications play nice in the SQL cluster (I have seen this from my > own experience when one bad vendor app on a shared SQL instance causes a > lot of issues)**** > > ** ** > > Food for thought, **** > > Z**** > > ** ** > > Edward E. Ziots, CISSP, CISA, Security +, Network +**** > > Security Engineer**** > > Lifespan Organization**** > > [email protected]**** > > Work:401-255-2497**** > > ** ** > > ** ** > > This electronic message and any attachments may be privileged and > confidential and protected from disclosure. If you are reading this > message, but are not the intended recipient, nor an employee or agent > responsible for delivering this message to the intended recipient, you are > hereby notified that you are strictly prohibited from copying, printing, > forwarding or otherwise disseminating this communication. If you have > received this communication in error, please immediately notify the sender > by replying to the message. Then, delete the message from your computer. > Thank you.**** > > *[image: Description: Description: Lifespan]* > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *David McSpadden > *Sent:* Monday, August 12, 2013 3:50 PM > *To:* [email protected] > *Subject:* RE: [NTSysADM] RE: Virtualization of servers in the production > room?**** > > ** ** > > Getting them from the vendors. I have what is being used over the last 30 > days but that is serverwide not just SQL. I am getting the vendors to give > me their best guess as to what their software requires.**** > > J**** > > ** ** > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Michael B. Smith > *Sent:* Monday, August 12, 2013 3:45 PM > *To:* [email protected] > *Subject:* [NTSysADM] RE: Virtualization of servers in the production > room?**** > > ** ** > > Do you know your IOPS, memory, and processor requirements?**** > > ** ** > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *David McSpadden > *Sent:* Monday, August 12, 2013 3:40 PM > *To:* [email protected] > *Subject:* [NTSysADM] Virtualization of servers in the production room?*** > * > > ** ** > > In reading and listening to some classes could I or should I take a my SQL > instances out of all my physical boxes and make one VM server of just SQL > and have all the installs that need SQL point to it so I end up having SQL > on one VM box and odbc connectivity to it?**** > > ** ** > > ** ** > > *Thank you* > > * * > > *David W. McSpadden* > > * * > > *B*egin Planning**** > > *A*rrange for Reconnaissance and Coordination**** > > *M*ake Reconnaissance**** > > *C*omplete Plan**** > > *I*ssue Order**** > > *S*upervise**** > > ** ** > > This e-mail and any files transmitted with it are property of Indiana > Members Credit Union, are confidential, and are intended solely for the use > of the individual or entity to whom this e-mail is addressed. If you are > not one of the named recipient(s) or otherwise have reason to believe that > you have received this message in error, please notify the sender and > delete this message immediately from your computer. Any other use, > retention, dissemination, forwarding, printing, or copying of this email is > strictly prohibited.**** > > ** ** > > Please consider the environment before printing this email.**** > > This e-mail and any files transmitted with it are property of Indiana > Members Credit Union, are confidential, and are intended solely for the use > of the individual or entity to whom this e-mail is addressed. If you are > not one of the named recipient(s) or otherwise have reason to believe that > you have received this message in error, please notify the sender and > delete this message immediately from your computer. Any other use, > retention, dissemination, forwarding, printing, or copying of this email is > strictly prohibited.**** > > ** ** > > Please consider the environment before printing this email.**** >
<<image001.jpg>>
