Failed SP2 install causing SQL service to fail...

  • Couldn't agree more Ken! 🙂

  • I think everyone needs to keep asking this question every time we attend a Microsoft function. Scream it if we have to. I know I've dealt with this through several versions of SQL Server. Maybe if we keep harassing them about it they'll do something.

    “If you're not outraged at the media, you haven't been paying attention.”

  • It took a lot of time on technet and google to track this down, it still happened after moving all the Dbs back to their original homes. there is a bug and it is fixable but I dont remember the kb article that eventualy explained what was happening. I was so relieved that it finally worked and I didnt have to wipe the box, format the disk and start again that all knowledge of it left my memory immediately:hehe:

  • I am surprised at how often I see threads where SQL has been installed and then the system databases moved immediately afterwards, why not get the install to place the databases where you want them in the first place?

    Also, don't seperate system database data and log files, these databases are not updated often enough for there to be any point or benefit in this (apart from tempdb perhaps), and as you have found out it just causes you grief.

    resources db is exclusively read only, so no point at all seperating out tran log, and master is rarely updated, so same thing.

    master and resources databases must be together or your upgrades will fail., knowing that, keep them together.

    ---------------------------------------------------------------------

  • I agree with you on the point that there is not a lot of activity on the system databases. However, I still separate them because I want to keep data files separated from program files to the greatest extent possible. I think I will start doing what Ed Vessie suggested: keep master and resource in the default location and move the other system databases.

    george sibbald (10/29/2008)


    I am surprised at how often I see threads where SQL has been installed and then the system databases moved immediately afterwards, why not get the install to place the databases where you want them in the first place?

    Also, don't seperate system database data and log files, these databases are not updated often enough for there to be any point or benefit in this (apart from tempdb perhaps), and as you have found out it just causes you grief.

    resources db is exclusively read only, so no point at all seperating out tran log, and master is rarely updated, so same thing.

    master and resources databases must be together or your upgrades will fail., knowing that, keep them together.

    “If you're not outraged at the media, you haven't been paying attention.”

  • Ken,

    I think Ed was saying keep master and resources in ORIGINAL location, not necessarily DEFAULT location. During the install if you go into advanced options, you can separate your program files from your data files (i.e. system databases) as much as you want to. Do it then and you will not have to move any system databases afterwards.

    Any articles referring to separating out data and log, they don't mean system databases as well (if they do they are wrong IMHO).

    ---------------------------------------------------------------------

  • I'd agree with George. Data/log separation isn't necessary for system databases. Or if it is, you're likely doing something strange in there.

  • Do you keep them on the same disk as the operating system and program files, or do you keep them somewhere else?

    Steve Jones - Editor (10/30/2008)


    I'd agree with George. Data/log separation isn't necessary for system databases. Or if it is, you're likely doing something strange in there.

    “If you're not outraged at the media, you haven't been paying attention.”

  • Ken Powers (10/30/2008)


    Do you keep them on the same disk as the operating system and program files, or do you keep them somewhere else?

    In a perfect world, separated. Certainly separate them out from the OS, app program files you can get away with, i.e. in this sort of set up:

    C drive - OS

    E drive - app binaries + master model msdb, resources

    F drive - tempdb

    if its a small low use system tempdb could go on E as well

    in other words - away from OS but everything else - it depends (on performance\use requirements) 🙂

    ---------------------------------------------------------------------

  • Our standard configuration is:

    C - OS and Program Files

    D - TempDB data files

    E - Log Files

    F - Data Files

    G - Backup files

    Perhaps I could have both the data and log files for the other system databases on the F drive.

    george sibbald (10/30/2008)


    Ken Powers (10/30/2008)


    Do you keep them on the same disk as the operating system and program files, or do you keep them somewhere else?

    In a perfect world, separated. Certainly separate them out from the OS, app program files you can get away with, i.e. in this sort of set up:

    C drive - OS

    E drive - app binaries + master model msdb, resources

    F drive - tempdb

    if its a small low use system tempdb could go on E as well

    in other words - away from OS but everything else - it depends (on performance\use requirements) 🙂

    “If you're not outraged at the media, you haven't been paying attention.”

  • I try to keep to that configuration, it depends on the amount of money allowed for disks and the projected data size (always wrong)

  • I'd leave them all on the D drive, simplest , neatest, and least effort.

    ---------------------------------------------------------------------

Viewing 12 posts - 16 through 26 (of 26 total)

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