Copy Database Wizard Throughput?

Ok, so I'm trying to use the CDW to copy a SQL 2000 db to SQL 2005. The
original is composed of 2 or 3 data files and 1 translog file, total of about
12GB. I connected each server -- separate boxes -- to my internal network,
the SQL 2005 has a Gbit NIC, the 2000 server a 100MBit NIC. After 10+ hours,
the CDW is still processing and I can see that the largest of the ldf files
has copied over to the 2005 server, but basically I'm wondering, what's the
metric per GB of data to move, 1Gb/per hour? Has anyone else using the CDW
seen it work faster? Just seems a bit slow to me . . .
Thanks,
ChadHello,
I recommend you to do:-
1. Backup the SQL 2000 database
2. Copy the Backup file to SQL 2005 server
3. Restore the Backup file. This will automatically restore and upgrade the
database to SQL 2005
Thanks
Hari
"cc" <cc@.discussions.microsoft.com> wrote in message
news:21E0DBD4-D1C1-4539-85E9-E048EF0A4EDA@.microsoft.com...
> Ok, so I'm trying to use the CDW to copy a SQL 2000 db to SQL 2005. The
> original is composed of 2 or 3 data files and 1 translog file, total of
> about
> 12GB. I connected each server -- separate boxes -- to my internal
> network,
> the SQL 2005 has a Gbit NIC, the 2000 server a 100MBit NIC. After 10+
> hours,
> the CDW is still processing and I can see that the largest of the ldf
> files
> has copied over to the 2005 server, but basically I'm wondering, what's
> the
> metric per GB of data to move, 1Gb/per hour? Has anyone else using the
> CDW
> seen it work faster? Just seems a bit slow to me . . .
> Thanks,
>
> Chad|||On Feb 19, 8:37 pm, cc <c...@.discussions.microsoft.com> wrote:
> Ok, so I'm trying to use the CDW to copy a SQL 2000 db to SQL 2005. The
> original is composed of 2 or 3 data files and 1 translog file, total of about
> 12GB. I connected each server -- separate boxes -- to my internal network,
> the SQL 2005 has a Gbit NIC, the 2000 server a 100MBit NIC. After 10+ hours,
> the CDW is still processing and I can see that the largest of the ldf files
> has copied over to the 2005 server, but basically I'm wondering, what's the
> metric per GB of data to move, 1Gb/per hour? Has anyone else using the CDW
> seen it work faster? Just seems a bit slow to me . . .
> Thanks,
> Chad
That wizard does the equivalent of you scripting and creating each
individual database object, followed by a INSERT INTO/SELECT * for
each table. It's pretty much a toy with no real value. There are
better, accepted methods for transferring a database between servers:
1. BACKUP/RESTORE - preferred if downtime is a concern, can be done
without taking the host DB offline
2. Detach/reattach - preferred if a clean cutoff is required, host DB
is taken offline, copied to the new location, then brought back
online.
Both are much faster and simpler than the copy wizard.|||It looks like I'll go the sp_detach route. I had tried CDW with some <100mb
dbs and it went smoothly and quickly, but this one actually croaked. Well,
to be specific, I thought maybe I had too many GUI resources open, and in
Win2003, the SQL Mgr and CDW both appear as separate graphical entities, so I
killed the SQL MGR, which took the CDW down, just like that, no warnings, no
rollback at all. Fortunately, I was able to reattach the mdf files on the
origin server. Sigh.
"Tracy McKibben" wrote:
> On Feb 19, 8:37 pm, cc <c...@.discussions.microsoft.com> wrote:
> > Ok, so I'm trying to use the CDW to copy a SQL 2000 db to SQL 2005. The
> > original is composed of 2 or 3 data files and 1 translog file, total of about
> > 12GB. I connected each server -- separate boxes -- to my internal network,
> > the SQL 2005 has a Gbit NIC, the 2000 server a 100MBit NIC. After 10+ hours,
> > the CDW is still processing and I can see that the largest of the ldf files
> > has copied over to the 2005 server, but basically I'm wondering, what's the
> > metric per GB of data to move, 1Gb/per hour? Has anyone else using the CDW
> > seen it work faster? Just seems a bit slow to me . . .
> >
> > Thanks,
> >
> > Chad
>
> That wizard does the equivalent of you scripting and creating each
> individual database object, followed by a INSERT INTO/SELECT * for
> each table. It's pretty much a toy with no real value. There are
> better, accepted methods for transferring a database between servers:
> 1. BACKUP/RESTORE - preferred if downtime is a concern, can be done
> without taking the host DB offline
> 2. Detach/reattach - preferred if a clean cutoff is required, host DB
> is taken offline, copied to the new location, then brought back
> online.
> Both are much faster and simpler than the copy wizard.
>
>

Copied Package ConnectionManager has photographic memory?

I originally made 1 package, got it the way I wanted with configurations,etc, and then made 30 copies of it, renaming, etc.

The original package (and the copies) has 2 connections. Connection A is set at runtime by a configuration from an XML file. Connection B is set from a SQL Server lookup from Connection A.

I'm now trying to run one of those copied packages. As I mentioned, in my package I have 2 connections. I changed one of my connections, save the package, go back and look at the connection, and the initial catalog has changed. Life is good, right? Wrong. I close the package, go back in, and the initial catalog is back to the original. If I look at the package's XML in notepad, I see the correct new connection manager. So where is it picking up this info from?

Interestingly, if I delete the connection, add a new connection, rename it to the original connection I had (so my configuration will still be good), save it, close it, go back in, it still reverts back to that original connection.

Whats the deal? Its almost like I have to name my connections differently across packages?Check if it is configured in the configuration settings
(in this case it is loaded from config provider) or
maybe in the property expressions (in which case it
is calculated).|||wow. I must be burnt out. I see the problem. User error. thanks

Copied database maintains original name in backups

I made a copy of a database "sac_prod" and named the new copy "vgs_prod". Now, when I do a backup of the new database, it still shows the name of the original. Is there any way to change this so it will be the same as the new database name?
Here is the BACKUP script:
BACKUPdatabase vgs_prod TODISK=
'\\sac-srvr1\data$\Technical\Shared\Production\SQLBackup\ LasVegas\vgs_prod_CopyOnly.BAK'
with COPY_ONLY
Here is the messages I received from this BACKUP:
Processed 1752 pages for database 'vgs_prod', file 'sac_prod' on file 1.
Processed 6 pages for database 'vgs_prod', file 'sac_prod_log' on file 1.
BACKUP DATABASE successfully processed 1758 pages in 0.412 seconds (34.955 MB/sec).

I would like to change the file 'sac_prod' to be 'vgs_prod' in lines 1 and 2 just above.

Thanks,it is the logical file name being displayed. it should not create any problem anywhere. still if u want to change

alter database vgs_prod modify file (NAME = 'sac_prod' , NEWNAME = 'vgs_prod')|||Thank you. I will be working with this later today.