Hi all!
I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes. This
needs to be available as close to 24/7 as possible.
My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning I
can't just detach the DB, move the MDF file, and re-attach).
My original idea was to:
1) Increase the size of the RA2.ndf file to 40G to allow it to hold all of
the data
2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
4) In theory my MDF file would now be small and I could detach, move the
file, re-attach in a minute. In practice it seems that the MDF file is still
about 20G, even though SQL server reports using only a very little bit of it.
Steps 1 and 2 work fine, howeve I can't seem to physically shrink the MDF
file. Is there a way around this issue?
Thanks in advance for any help you can provide!
-Phil Mattson
How about using Log Shipping or a SQL Server cluster?
Rick Sawtell
MCT, MCSD, MCDBA
"pmattson" <pmattson@.discussions.microsoft.com> wrote in message
news:9E08DE35-7360-4CE0-938A-F3219A8889D6@.microsoft.com...
> Hi all!
> I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
> y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes.
This
> needs to be available as close to 24/7 as possible.
> My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning I
> can't just detach the DB, move the MDF file, and re-attach).
> My original idea was to:
> 1) Increase the size of the RA2.ndf file to 40G to allow it to hold all of
> the data
> 2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
> 3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
> 4) In theory my MDF file would now be small and I could detach, move the
> file, re-attach in a minute. In practice it seems that the MDF file is
still
> about 20G, even though SQL server reports using only a very little bit of
it.
> Steps 1 and 2 work fine, howeve I can't seem to physically shrink the MDF
> file. Is there a way around this issue?
> Thanks in advance for any help you can provide!
> -Phil Mattson
|||If I hear you right what you're saying is:
1) Restore my RA database as a different DB (Say RA2) onto drive z:
2) Log ship (or manually) restore transaction log backups of RA into RA2.
3) When I'm ready to "move" my database then rename the Databases so that
RA2 becomes RA. I believe that might work for me.
Any other ideas? I'm a little concerned that my server may not be able to
handle the total amount of IO activity "log shipping" my very active RA
database transaction logs and applying them to a RA2 database.
"Rick Sawtell" wrote:
> How about using Log Shipping or a SQL Server cluster?
>
> Rick Sawtell
> MCT, MCSD, MCDBA
>
> "pmattson" <pmattson@.discussions.microsoft.com> wrote in message
> news:9E08DE35-7360-4CE0-938A-F3219A8889D6@.microsoft.com...
> This
> still
> it.
>
>
|||If you have that much activity going on, get another server or an additional
processor. <wink>
You check your real activity levels with System Monitor and SQL Server
Profiler tools. See how much activity you are really supporting.
Rick Sawtell
MCT, MCSD, MCDBA
"pmattson" <pmattson@.discussions.microsoft.com> wrote in message
news:E58441F3-7D59-4388-844F-6682E6F5B117@.microsoft.com...[vbcol=seagreen]
> If I hear you right what you're saying is:
> 1) Restore my RA database as a different DB (Say RA2) onto drive z:
> 2) Log ship (or manually) restore transaction log backups of RA into RA2.
> 3) When I'm ready to "move" my database then rename the Databases so that
> RA2 becomes RA. I believe that might work for me.
> Any other ideas? I'm a little concerned that my server may not be able to
> handle the total amount of IO activity "log shipping" my very active RA
> database transaction logs and applying them to a RA2 database.
> "Rick Sawtell" wrote:
I[vbcol=seagreen]
all of[vbcol=seagreen]
the[vbcol=seagreen]
of[vbcol=seagreen]
MDF[vbcol=seagreen]
Showing posts with label datafiles. Show all posts
Showing posts with label datafiles. Show all posts
Friday, March 9, 2012
Move Large MDF file
Hi all!
I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes. This
needs to be available as close to 24/7 as possible.
My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning I
can't just detach the DB, move the MDF file, and re-attach).
My original idea was to:
1) Increase the size of the RA2.ndf file to 40G to allow it to hold all of
the data
2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
4) In theory my MDF file would now be small and I could detach, move the
file, re-attach in a minute. In practice it seems that the MDF file is still
about 20G, even though SQL server reports using only a very little bit of it.
Steps 1 and 2 work fine, howeve I can't seem to physically shrink the MDF
file. Is there a way around this issue?
Thanks in advance for any help you can provide!
-Phil MattsonHow about using Log Shipping or a SQL Server cluster?
Rick Sawtell
MCT, MCSD, MCDBA
"pmattson" <pmattson@.discussions.microsoft.com> wrote in message
news:9E08DE35-7360-4CE0-938A-F3219A8889D6@.microsoft.com...
> Hi all!
> I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
> y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes.
This
> needs to be available as close to 24/7 as possible.
> My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning I
> can't just detach the DB, move the MDF file, and re-attach).
> My original idea was to:
> 1) Increase the size of the RA2.ndf file to 40G to allow it to hold all of
> the data
> 2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
> 3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
> 4) In theory my MDF file would now be small and I could detach, move the
> file, re-attach in a minute. In practice it seems that the MDF file is
still
> about 20G, even though SQL server reports using only a very little bit of
it.
> Steps 1 and 2 work fine, howeve I can't seem to physically shrink the MDF
> file. Is there a way around this issue?
> Thanks in advance for any help you can provide!
> -Phil Mattson|||If I hear you right what you're saying is:
1) Restore my RA database as a different DB (Say RA2) onto drive z:
2) Log ship (or manually) restore transaction log backups of RA into RA2.
3) When I'm ready to "move" my database then rename the Databases so that
RA2 becomes RA. I believe that might work for me.
Any other ideas? I'm a little concerned that my server may not be able to
handle the total amount of IO activity "log shipping" my very active RA
database transaction logs and applying them to a RA2 database.
"Rick Sawtell" wrote:
> How about using Log Shipping or a SQL Server cluster?
>
> Rick Sawtell
> MCT, MCSD, MCDBA
>
> "pmattson" <pmattson@.discussions.microsoft.com> wrote in message
> news:9E08DE35-7360-4CE0-938A-F3219A8889D6@.microsoft.com...
> > Hi all!
> >
> > I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
> > y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes.
> This
> > needs to be available as close to 24/7 as possible.
> >
> > My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning I
> > can't just detach the DB, move the MDF file, and re-attach).
> >
> > My original idea was to:
> > 1) Increase the size of the RA2.ndf file to 40G to allow it to hold all of
> > the data
> > 2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
> > 3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
> > 4) In theory my MDF file would now be small and I could detach, move the
> > file, re-attach in a minute. In practice it seems that the MDF file is
> still
> > about 20G, even though SQL server reports using only a very little bit of
> it.
> >
> > Steps 1 and 2 work fine, howeve I can't seem to physically shrink the MDF
> > file. Is there a way around this issue?
> >
> > Thanks in advance for any help you can provide!
> >
> > -Phil Mattson
>
>|||If you have that much activity going on, get another server or an additional
processor. <wink>
You check your real activity levels with System Monitor and SQL Server
Profiler tools. See how much activity you are really supporting.
Rick Sawtell
MCT, MCSD, MCDBA
"pmattson" <pmattson@.discussions.microsoft.com> wrote in message
news:E58441F3-7D59-4388-844F-6682E6F5B117@.microsoft.com...
> If I hear you right what you're saying is:
> 1) Restore my RA database as a different DB (Say RA2) onto drive z:
> 2) Log ship (or manually) restore transaction log backups of RA into RA2.
> 3) When I'm ready to "move" my database then rename the Databases so that
> RA2 becomes RA. I believe that might work for me.
> Any other ideas? I'm a little concerned that my server may not be able to
> handle the total amount of IO activity "log shipping" my very active RA
> database transaction logs and applying them to a RA2 database.
> "Rick Sawtell" wrote:
> > How about using Log Shipping or a SQL Server cluster?
> >
> >
> > Rick Sawtell
> > MCT, MCSD, MCDBA
> >
> >
> > "pmattson" <pmattson@.discussions.microsoft.com> wrote in message
> > news:9E08DE35-7360-4CE0-938A-F3219A8889D6@.microsoft.com...
> > > Hi all!
> > >
> > > I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
> > > y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes.
> > This
> > > needs to be available as close to 24/7 as possible.
> > >
> > > My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning
I
> > > can't just detach the DB, move the MDF file, and re-attach).
> > >
> > > My original idea was to:
> > > 1) Increase the size of the RA2.ndf file to 40G to allow it to hold
all of
> > > the data
> > > 2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
> > > 3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
> > > 4) In theory my MDF file would now be small and I could detach, move
the
> > > file, re-attach in a minute. In practice it seems that the MDF file is
> > still
> > > about 20G, even though SQL server reports using only a very little bit
of
> > it.
> > >
> > > Steps 1 and 2 work fine, howeve I can't seem to physically shrink the
MDF
> > > file. Is there a way around this issue?
> > >
> > > Thanks in advance for any help you can provide!
> > >
> > > -Phil Mattson
> >
> >
> >
I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes. This
needs to be available as close to 24/7 as possible.
My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning I
can't just detach the DB, move the MDF file, and re-attach).
My original idea was to:
1) Increase the size of the RA2.ndf file to 40G to allow it to hold all of
the data
2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
4) In theory my MDF file would now be small and I could detach, move the
file, re-attach in a minute. In practice it seems that the MDF file is still
about 20G, even though SQL server reports using only a very little bit of it.
Steps 1 and 2 work fine, howeve I can't seem to physically shrink the MDF
file. Is there a way around this issue?
Thanks in advance for any help you can provide!
-Phil MattsonHow about using Log Shipping or a SQL Server cluster?
Rick Sawtell
MCT, MCSD, MCDBA
"pmattson" <pmattson@.discussions.microsoft.com> wrote in message
news:9E08DE35-7360-4CE0-938A-F3219A8889D6@.microsoft.com...
> Hi all!
> I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
> y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes.
This
> needs to be available as close to 24/7 as possible.
> My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning I
> can't just detach the DB, move the MDF file, and re-attach).
> My original idea was to:
> 1) Increase the size of the RA2.ndf file to 40G to allow it to hold all of
> the data
> 2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
> 3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
> 4) In theory my MDF file would now be small and I could detach, move the
> file, re-attach in a minute. In practice it seems that the MDF file is
still
> about 20G, even though SQL server reports using only a very little bit of
it.
> Steps 1 and 2 work fine, howeve I can't seem to physically shrink the MDF
> file. Is there a way around this issue?
> Thanks in advance for any help you can provide!
> -Phil Mattson|||If I hear you right what you're saying is:
1) Restore my RA database as a different DB (Say RA2) onto drive z:
2) Log ship (or manually) restore transaction log backups of RA into RA2.
3) When I'm ready to "move" my database then rename the Databases so that
RA2 becomes RA. I believe that might work for me.
Any other ideas? I'm a little concerned that my server may not be able to
handle the total amount of IO activity "log shipping" my very active RA
database transaction logs and applying them to a RA2 database.
"Rick Sawtell" wrote:
> How about using Log Shipping or a SQL Server cluster?
>
> Rick Sawtell
> MCT, MCSD, MCDBA
>
> "pmattson" <pmattson@.discussions.microsoft.com> wrote in message
> news:9E08DE35-7360-4CE0-938A-F3219A8889D6@.microsoft.com...
> > Hi all!
> >
> > I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
> > y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes.
> This
> > needs to be available as close to 24/7 as possible.
> >
> > My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning I
> > can't just detach the DB, move the MDF file, and re-attach).
> >
> > My original idea was to:
> > 1) Increase the size of the RA2.ndf file to 40G to allow it to hold all of
> > the data
> > 2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
> > 3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
> > 4) In theory my MDF file would now be small and I could detach, move the
> > file, re-attach in a minute. In practice it seems that the MDF file is
> still
> > about 20G, even though SQL server reports using only a very little bit of
> it.
> >
> > Steps 1 and 2 work fine, howeve I can't seem to physically shrink the MDF
> > file. Is there a way around this issue?
> >
> > Thanks in advance for any help you can provide!
> >
> > -Phil Mattson
>
>|||If you have that much activity going on, get another server or an additional
processor. <wink>
You check your real activity levels with System Monitor and SQL Server
Profiler tools. See how much activity you are really supporting.
Rick Sawtell
MCT, MCSD, MCDBA
"pmattson" <pmattson@.discussions.microsoft.com> wrote in message
news:E58441F3-7D59-4388-844F-6682E6F5B117@.microsoft.com...
> If I hear you right what you're saying is:
> 1) Restore my RA database as a different DB (Say RA2) onto drive z:
> 2) Log ship (or manually) restore transaction log backups of RA into RA2.
> 3) When I'm ready to "move" my database then rename the Databases so that
> RA2 becomes RA. I believe that might work for me.
> Any other ideas? I'm a little concerned that my server may not be able to
> handle the total amount of IO activity "log shipping" my very active RA
> database transaction logs and applying them to a RA2 database.
> "Rick Sawtell" wrote:
> > How about using Log Shipping or a SQL Server cluster?
> >
> >
> > Rick Sawtell
> > MCT, MCSD, MCDBA
> >
> >
> > "pmattson" <pmattson@.discussions.microsoft.com> wrote in message
> > news:9E08DE35-7360-4CE0-938A-F3219A8889D6@.microsoft.com...
> > > Hi all!
> > >
> > > I've got a fairly large database that has 2 datafiles (x:\ra.mdf and
> > > y:\ra2.ndf). ra.mdf is about 20G bytes and ra2.ndf is about 15G bytes.
> > This
> > > needs to be available as close to 24/7 as possible.
> > >
> > > My goal is move x:\ra.mdf to z:\ra.mdf with minimal downtime. (Meaning
I
> > > can't just detach the DB, move the MDF file, and re-attach).
> > >
> > > My original idea was to:
> > > 1) Increase the size of the RA2.ndf file to 40G to allow it to hold
all of
> > > the data
> > > 2) DBCC SHRINKFILE (RA_Data, EMPTYFILE)
> > > 3) DBCC SHRINKFILE(RA_Data, TRUNCATEONLY)
> > > 4) In theory my MDF file would now be small and I could detach, move
the
> > > file, re-attach in a minute. In practice it seems that the MDF file is
> > still
> > > about 20G, even though SQL server reports using only a very little bit
of
> > it.
> > >
> > > Steps 1 and 2 work fine, howeve I can't seem to physically shrink the
MDF
> > > file. Is there a way around this issue?
> > >
> > > Thanks in advance for any help you can provide!
> > >
> > > -Phil Mattson
> >
> >
> >
Saturday, February 25, 2012
move datafiles to SAN
Is there a way to move data files to SAN without causing downtime to sql server
Apparently not .. Sorry
"sivan" <sivan@.discussions.microsoft.com> wrote in message
news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> Is there a way to move data files to SAN without causing downtime to sql
server
|||Hi,
You have to detach the database and then copy the files to SAN drive and then
attach it back. As soon as you detach the database , the database will not
be available till you attach it back.
FYI, ALL the other databases in the same instance will be available during
this time.
Thanks
Hari
MCDBA
"Hassan" wrote:
> Apparently not .. Sorry
> "sivan" <sivan@.discussions.microsoft.com> wrote in message
> news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> server
>
>
|||"Hari Prasad" <HariPrasad@.discussions.microsoft.com> wrote in message
news:BF369363-8765-48E0-9C2C-27857A2312ED@.microsoft.com...
> Hi,
> You have to detach the database and then copy the files to SAN drive and
then
> attach it back. As soon as you detach the database , the database will not
> be available till you attach it back.
>
There's one way that may minimize downtime.
Backup your databases and restore them with a new name (this time located on
the SAN).
Then stop activity to the DB Server, perform a transaction log backup of the
databases, restore those to the new databases, drop the old databases,
rename the new ones and you SHOULD be good to go.
If you script it, your downtime can be measured in minutes.
But I would practice this a LOT.
[vbcol=seagreen]
> FYI, ALL the other databases in the same instance will be available during
> this time.
> Thanks
> Hari
> MCDBA
>
>
> "Hassan" wrote:
sql[vbcol=seagreen]
Apparently not .. Sorry
"sivan" <sivan@.discussions.microsoft.com> wrote in message
news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> Is there a way to move data files to SAN without causing downtime to sql
server
|||Hi,
You have to detach the database and then copy the files to SAN drive and then
attach it back. As soon as you detach the database , the database will not
be available till you attach it back.
FYI, ALL the other databases in the same instance will be available during
this time.
Thanks
Hari
MCDBA
"Hassan" wrote:
> Apparently not .. Sorry
> "sivan" <sivan@.discussions.microsoft.com> wrote in message
> news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> server
>
>
|||"Hari Prasad" <HariPrasad@.discussions.microsoft.com> wrote in message
news:BF369363-8765-48E0-9C2C-27857A2312ED@.microsoft.com...
> Hi,
> You have to detach the database and then copy the files to SAN drive and
then
> attach it back. As soon as you detach the database , the database will not
> be available till you attach it back.
>
There's one way that may minimize downtime.
Backup your databases and restore them with a new name (this time located on
the SAN).
Then stop activity to the DB Server, perform a transaction log backup of the
databases, restore those to the new databases, drop the old databases,
rename the new ones and you SHOULD be good to go.
If you script it, your downtime can be measured in minutes.
But I would practice this a LOT.
[vbcol=seagreen]
> FYI, ALL the other databases in the same instance will be available during
> this time.
> Thanks
> Hari
> MCDBA
>
>
> "Hassan" wrote:
sql[vbcol=seagreen]
move datafiles to SAN
Is there a way to move data files to SAN without causing downtime to sql serverApparently not .. Sorry
"sivan" <sivan@.discussions.microsoft.com> wrote in message
news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> Is there a way to move data files to SAN without causing downtime to sql
server|||Hi,
You have to detach the database and then copy the files to SAN drive and then
attach it back. As soon as you detach the database , the database will not
be available till you attach it back.
FYI, ALL the other databases in the same instance will be available during
this time.
Thanks
Hari
MCDBA
"Hassan" wrote:
> Apparently not .. Sorry
> "sivan" <sivan@.discussions.microsoft.com> wrote in message
> news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> > Is there a way to move data files to SAN without causing downtime to sql
> server
>
>|||"Hari Prasad" <HariPrasad@.discussions.microsoft.com> wrote in message
news:BF369363-8765-48E0-9C2C-27857A2312ED@.microsoft.com...
> Hi,
> You have to detach the database and then copy the files to SAN drive and
then
> attach it back. As soon as you detach the database , the database will not
> be available till you attach it back.
>
There's one way that may minimize downtime.
Backup your databases and restore them with a new name (this time located on
the SAN).
Then stop activity to the DB Server, perform a transaction log backup of the
databases, restore those to the new databases, drop the old databases,
rename the new ones and you SHOULD be good to go.
If you script it, your downtime can be measured in minutes.
But I would practice this a LOT.
> FYI, ALL the other databases in the same instance will be available during
> this time.
> Thanks
> Hari
> MCDBA
>
>
> "Hassan" wrote:
> > Apparently not .. Sorry
> >
> > "sivan" <sivan@.discussions.microsoft.com> wrote in message
> > news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> > > Is there a way to move data files to SAN without causing downtime to
sql
> > server
> >
> >
> >
"sivan" <sivan@.discussions.microsoft.com> wrote in message
news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> Is there a way to move data files to SAN without causing downtime to sql
server|||Hi,
You have to detach the database and then copy the files to SAN drive and then
attach it back. As soon as you detach the database , the database will not
be available till you attach it back.
FYI, ALL the other databases in the same instance will be available during
this time.
Thanks
Hari
MCDBA
"Hassan" wrote:
> Apparently not .. Sorry
> "sivan" <sivan@.discussions.microsoft.com> wrote in message
> news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> > Is there a way to move data files to SAN without causing downtime to sql
> server
>
>|||"Hari Prasad" <HariPrasad@.discussions.microsoft.com> wrote in message
news:BF369363-8765-48E0-9C2C-27857A2312ED@.microsoft.com...
> Hi,
> You have to detach the database and then copy the files to SAN drive and
then
> attach it back. As soon as you detach the database , the database will not
> be available till you attach it back.
>
There's one way that may minimize downtime.
Backup your databases and restore them with a new name (this time located on
the SAN).
Then stop activity to the DB Server, perform a transaction log backup of the
databases, restore those to the new databases, drop the old databases,
rename the new ones and you SHOULD be good to go.
If you script it, your downtime can be measured in minutes.
But I would practice this a LOT.
> FYI, ALL the other databases in the same instance will be available during
> this time.
> Thanks
> Hari
> MCDBA
>
>
> "Hassan" wrote:
> > Apparently not .. Sorry
> >
> > "sivan" <sivan@.discussions.microsoft.com> wrote in message
> > news:958C0429-77A1-44F8-B38E-F7DED1BC6766@.microsoft.com...
> > > Is there a way to move data files to SAN without causing downtime to
sql
> > server
> >
> >
> >
Move datafile
Hi,
I need to move some datafiles from E to F. These datafiles are into of the filegroups.
i.e:
Actual
FILEGROUP: CDL_DATA e CDL_IDX
DATAFILE'S: e:\data\Cdl_data.NDF e e:\data\Cdl_idx_data.NDF
Changed
FILEGROUP: CDL_DATA e CDL_IDX
DATAFILE'S: F:\data\Cdl_data.NDF e F:\data\Cdl_idx_data.NDF
Is there a easy way by Enterprise Manager that I can do this job?
Thank you by atentionHi,
You can move datafiles of a DB using Detach & Attach procs..
Search for 'sp_detachdb' eg in BOL.. its straightforward mate..
cheers
ganesh
I need to move some datafiles from E to F. These datafiles are into of the filegroups.
i.e:
Actual
FILEGROUP: CDL_DATA e CDL_IDX
DATAFILE'S: e:\data\Cdl_data.NDF e e:\data\Cdl_idx_data.NDF
Changed
FILEGROUP: CDL_DATA e CDL_IDX
DATAFILE'S: F:\data\Cdl_data.NDF e F:\data\Cdl_idx_data.NDF
Is there a easy way by Enterprise Manager that I can do this job?
Thank you by atentionHi,
You can move datafiles of a DB using Detach & Attach procs..
Search for 'sp_detachdb' eg in BOL.. its straightforward mate..
cheers
ganesh
Subscribe to:
Posts (Atom)