Is this is the Best Practice to select E: for the SQL Server root directory?

  • Hi Experts,

    Is this is the Best Practice to select E: or any other driver(not C:) for the SQL Server root directory? Please let me know the Pros/cons and the practices to be followed.

    Thanks a lot in adavance

  • Sqlism (3/11/2013)


    Hi Experts,

    Is this is the Best Practice to select E: for the SQL Server root directory? Please let me know the Pros/cons and the practices to be followed.

    Thanks a lot in adavance

    Not really sure what you are asking but I can say that would not be a great practice for me since I don't have an E: drive. 😉

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Normally, from my experience, SQL binaries goes to D: drive and separate data, log and temdb to different drives based on your environment standards.

    SueTons.

    Regards,
    SQLisAwe5oMe.

  • Thanks for the reply, so u suggest to seperate sql

    Binaries from

    OS binaries ?

    My question is , is this is the best practice to change root directory from default location in c drive to any other drive. Is so what are the advantages and disasvantages... Any. Suggestions please

  • Sqlism (3/11/2013)


    Thanks for the reply, so u suggest to seperate sql

    Binaries from

    OS binaries ?

    My question is , is this is the best practice to change root directory from default location in c drive to any other drive. Is so what are the advantages and disasvantages... Any. Suggestions please

    When you install SQL, C: drive is the root directory, we leave the system databases(except tempdb) on D: drive and separate the data & log(user databases) and tempdb to different drives.

    SueTons.

    Regards,
    SQLisAwe5oMe.

  • SQLCrazyCertified (3/11/2013)


    Sqlism (3/11/2013)


    Thanks for the reply, so u suggest to seperate sql

    Binaries from

    OS binaries ?

    My question is , is this is the best practice to change root directory from default location in c drive to any other drive. Is so what are the advantages and disasvantages... Any. Suggestions please

    When you install SQL, C: drive is the root directory, we leave the system databases(except tempdb) on D: drive and separate the data & log(user databases) and tempdb to different drives.

    SueTons.

    Correction, D: drive should be root for SQL......C: drive should be left alone for OS ONLY.

    SueTons.

    Regards,
    SQLisAwe5oMe.

  • ... and this includes the location for the Shared Features, such as Management Studio and Integrated Services.

    One reason beyond this practices is that you are not installing any files on C:\. So if the

    C:\ drive starts getting full, the Windows/Server team cannot come to you with a stick asking you to clear space.

  • Sqlism (3/11/2013)


    Hi Experts,

    Is this is the Best Practice to select E: for the SQL Server root directory? Please let me know the Pros/cons and the practices to be followed.

    Thanks a lot in adavance

    No. "Best Practice" couldn't possibly be a specific drive letter, since different sites will have vastly different types of "E:" drives, or, as noted, no E: drive at all.

    Is it "Best Practice" to use a separate drive from Windows? Maybe. You may want/need to separate SQL from the paging dataset, depending on activity. Or it may not be necessary at all.

    SQL may place some things in a specific, "core" folder anyway, and you won't have control over that.

    SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.

  • Thanks for the reply

    I mean to say any other driver other than C drive. I specified E drive as example. sorry for the confusion. So can someone conclude that it is best practice to change SQL Binaries from OS Binaries?

    Thanks again 🙂

  • Sqlism (3/11/2013)


    Thanks for the reply

    I mean to say any other driver other than C drive. I specified E drive as example. sorry for the confusion. So can someone conclude that it is best practice to change SQL Binaries from OS Binaries?

    Thanks again 🙂

    Yes, absolutely, otherwise if your C drive run out space, system will crash.

    So, leave C drive alone to OS.

    SueTons.

    Regards,
    SQLisAwe5oMe.

  • Sqlism (3/11/2013)


    Thanks for the reply

    I mean to say any other driver other than C drive. I specified E drive as example. sorry for the confusion. So can someone conclude that it is best practice to change SQL Binaries from OS Binaries?

    Thanks again 🙂

    Binaries - imho, not really. You end up installing plenty of pieces of SQL server on the OS drive regardless of specifying to install SQL to a different drive.

    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

  • I am not sure there is a best practice on this any more. Back in SQL 2000 and NT4 days people normally installed programs in a separate drive to the OS, and a OS drive size of 5GB was more or less standard.

    With SQL 2005 and Windows 2003 the situation changed, because the SQL install always puts about 3GB on to the system drive, and only about 0.5GB on the 'program' drive. This has continued into SQL 2012 and Windows 2012, except that the numbers have become larger. When service packs and CUs are applied, the bulk of the updates will always go on to the system drive. Many people started to question if using a separate drive for SQL binaries was worth the effort.

    The latest builds at my organisation put the SQL binaries on to the system drive, but put the ssytem databases on to a separate drive. We allow 60Gb for the system drive, to cope with both OS and SQL fixes over the expected lifetime of the server.

    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

  • I see your point regarding space. But what about disk I/O ? Shouldn't be better to keep them apart, in separate physical drives?

    Miguel

  • I see your point regarding space. But what about disk I/O ? Shouldn't be better to keep them apart, in separate physical drives?

    Miguel

  • The majority of the disk IO is to the GAC. This always exists onthe C: drive.

    In any event, the IO to the OS and SQL binaries is in single digit IO per second (according to the PAL and Perfmon reports we have done) so IO load on the system drive if it does have any databases on it is negligable.

    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

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply