SQL Server Performance

Virtual Machine, Shared Folders (Network drive) and Trace flag 1807

Discussion in 'General DBA Questions' started by lookaround, Apr 23, 2010.

  1. lookaround New Member

    Hi everyone,
    I have a new dev machine with Windows 7 x64; to work on projects still using SQL Server 2000, i've setup a virtual machine with virtualbox running XP.
    On this machine i want to install SQL Server but storing db data files on the host (main) drive.
    The only way the host-guest share data is shared folders, so in the guest (XP) you can access host (Win7) folders as they were network drive (in reality they are direct attached drive).
    The problem came during installation, when SQL2K doesn't allow to set Data Files on a network drive, also if I map the network location to a drive letter (via UI, net use command and subst command); it always says "Invalid drive type. Choose a driver on the local machine".
    I know that microsoft discourages the use of network database files, but in my case they are only "masked" as network drive, in reality it's a direct attached one.
    Using trace flag 1807, SQLServer bypasses the check and allows you to configure SQL Server with network-based database files.
    The question: is the intrinsic protocol of network communication that doesn't guarantee write ordering and write-through or the problems occur only when the reads-writes happen actually on a network?
    So it is safe in my specific case to use this trick (considering that in case of a problem, beeing a dev machine, i could restore a backup with no problem..)?
    And as far as you know, is it possible to bypass the check in installation too (has it happens with trace flag 1807)?
    Thx in advance!
  2. ghemant Moderator

    AFAIK this is not supported, what you could do alternatively is to schedule a backup of your database files (offline or database backup on the external network - in this case it would be your Host operating system) . SQL Server 2000 is not supported, you should upgrade to SQL Server 2008, or atleast to SQL Server 2005!!!
  3. lookaround New Member

    Thanks for suggestion, at the end i came out simply using 1807 flag....

Share This Page