Hi,
I've read through the threads related to 2000-2005 upgrade I can find on
this newsgroup. From what I've gathered, seems there are the following three
ways to upgrade.
1. in place
2. install a new instance that runs 2005 on the same database server
3. Set up a different server and then install 2005 on it.
We're currently running SQL 2000 SP3 on windows 2003. Is it true that
installing SP4 on SQL 2000 is required before it can be brought up to 2005
for in place upgrade?
For the rest two, I'm not very clear which one is better.
If we do option 3, we need to make DNS changes for server IP/name move which
always doesn't happen right away in my environment. That would most likely
extend upgrade time. But the obvious benefit is in case something wrong
happens with the upgrade, I can have the original 2000 server to safely go
back to.
For option 2, would a new 2005 instance have any negative impact on the sql
2000 instance? Are them totally independent of each other? I need to know
for sure if the 2005 instance doesn't work, the 2000 still works fine.
I'd appreciate any insight or real world experience (better) regarding 2005
upgrade. Things don't always go the way as they are instructed in the doc.
Thanks,
BingUpgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
SP3.
About a side-by-side installation of SQL Server 2005, i'm currently running
on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
2005 instances; since the installation i've never had a problem.
The only important consideration in this case is: do i have sufficient RAM
for both instances? Surely you'll need to configure appropriately Min memory
and Max memory for each instance.
More: currently i'm administering my SQL Server 2000 instances from SQL
Server Management Studio.
Gilberto Zampatti
"bing" wrote:
> Hi,
> I've read through the threads related to 2000-2005 upgrade I can find on
> this newsgroup. From what I've gathered, seems there are the following three
> ways to upgrade.
> 1. in place
> 2. install a new instance that runs 2005 on the same database server
> 3. Set up a different server and then install 2005 on it.
> We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> installing SP4 on SQL 2000 is required before it can be brought up to 2005
> for in place upgrade?
> For the rest two, I'm not very clear which one is better.
> If we do option 3, we need to make DNS changes for server IP/name move which
> always doesn't happen right away in my environment. That would most likely
> extend upgrade time. But the obvious benefit is in case something wrong
> happens with the upgrade, I can have the original 2000 server to safely go
> back to.
> For option 2, would a new 2005 instance have any negative impact on the sql
> 2000 instance? Are them totally independent of each other? I need to know
> for sure if the 2005 instance doesn't work, the 2000 still works fine.
> I'd appreciate any insight or real world experience (better) regarding 2005
> upgrade. Things don't always go the way as they are instructed in the doc.
> Thanks,
> Bing|||Thanks for the response. RAM allocation is a very good point. Our SQL
server 2000 server (Standard) which is running only one instance currently
has 2G RAM. If I install 2005 (Standard) on the save server, that will
compete with 2000 for RAM.
Bing
"Gilberto Zampatti" wrote:
> Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> SP3.
> About a side-by-side installation of SQL Server 2005, i'm currently running
> on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> 2005 instances; since the installation i've never had a problem.
> The only important consideration in this case is: do i have sufficient RAM
> for both instances? Surely you'll need to configure appropriately Min memory
> and Max memory for each instance.
> More: currently i'm administering my SQL Server 2000 instances from SQL
> Server Management Studio.
> Gilberto Zampatti
> "bing" wrote:
> > Hi,
> >
> > I've read through the threads related to 2000-2005 upgrade I can find on
> > this newsgroup. From what I've gathered, seems there are the following three
> > ways to upgrade.
> >
> > 1. in place
> > 2. install a new instance that runs 2005 on the same database server
> > 3. Set up a different server and then install 2005 on it.
> >
> > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > for in place upgrade?
> >
> > For the rest two, I'm not very clear which one is better.
> >
> > If we do option 3, we need to make DNS changes for server IP/name move which
> > always doesn't happen right away in my environment. That would most likely
> > extend upgrade time. But the obvious benefit is in case something wrong
> > happens with the upgrade, I can have the original 2000 server to safely go
> > back to.
> >
> > For option 2, would a new 2005 instance have any negative impact on the sql
> > 2000 instance? Are them totally independent of each other? I need to know
> > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> >
> > I'd appreciate any insight or real world experience (better) regarding 2005
> > upgrade. Things don't always go the way as they are instructed in the doc.
> >
> > Thanks,
> >
> > Bing|||On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> Thanks for the response. RAM allocation is a very good point. Our SQL
> server 2000 server (Standard) which is running only one instance currently
> has 2G RAM. If I install 2005 (Standard) on the save server, that will
> compete with 2000 for RAM.
> Bing
>
> "Gilberto Zampatti" wrote:
> > Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> > SP3.
> > About a side-by-side installation of SQL Server 2005, i'm currently running
> > on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> > 2005 instances; since the installation i've never had a problem.
> > The only important consideration in this case is: do i have sufficient RAM
> > for both instances? Surely you'll need to configure appropriately Min memory
> > and Max memory for each instance.
> > More: currently i'm administering my SQL Server 2000 instances from SQL
> > Server Management Studio.
> > Gilberto Zampatti
> > "bing" wrote:
> > > Hi,
> > > I've read through the threads related to 2000-2005 upgrade I can find on
> > > this newsgroup. From what I've gathered, seems there are the following three
> > > ways to upgrade.
> > > 1. in place
> > > 2. install a new instance that runs 2005 on the same database server
> > > 3. Set up a different server and then install 2005 on it.
> > > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > > for in place upgrade?
> > > For the rest two, I'm not very clear which one is better.
> > > If we do option 3, we need to make DNS changes for server IP/name move which
> > > always doesn't happen right away in my environment. That would most likely
> > > extend upgrade time. But the obvious benefit is in case something wrong
> > > happens with the upgrade, I can have the original 2000 server to safely go
> > > back to.
> > > For option 2, would a new 2005 instance have any negative impact on the sql
> > > 2000 instance? Are them totally independent of each other? I need to know
> > > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> > > I'd appreciate any insight or real world experience (better) regarding 2005
> > > upgrade. Things don't always go the way as they are instructed in the doc.
> > > Thanks,
> > > Bing- Hide quoted text -
> - Show quoted text -
Here is my experience in a nutshell - as much as I remember anyway. I
just did a 2000 to 2005 upgrade for 8 production databases varying
from a few hundred megs to 50 gigs.This approach with a new server
allowed us to test and to hold cutting over until we were 100% sure
everything was working. There are may ways to do this, but this how I
did it....
We built and configured a new 2005 server first. Here is the overview
of the check list:
1. Build new server with network engineers.
2. Discuss best place to keep logfiles, databases, backups etc. Do
appropriate sizing etc.
3. Decide what new services to use and get them configured and
running. EX: We are not using analysis service.
4. Configure database mail.
5. Configure alerts and get backups going for system databases etc.
6. do a backup and restore from 2000 to 2005 and get the db backup and
log maintenence jobs going. I did weekly stats update and alter index
reorganize.
7. Created all windows, sql logins on the new box - we are mixed mode.
8. This allowed us to test the apps on the new server and permissions
etc. The schema's can be troublesome. I dropped all users after
restoring and then reapplied the permissions.
9.Here was my actual cutover checklist of things the SSIS package did
a. take down apps/or web server during cutover
b.backup 2000 databases to unc path
c.resotore databases to new 2005 box from unc path.
d.drop permissions (logins, schemas, roles, users)
e. re-assign permissions as required.
f.rebuild indexes
g.set database compatibility level (90) for 2005
h.re-point all applications to new SQL instance
i.run backup and maintenence jobs to make sure all working.
j.test and run other SSIS jobs
k.detach old 2005 databases but leave on the server for awhile in case
of issues.
Kristina|||"Kristina" wrote:
> On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> > Thanks for the response. RAM allocation is a very good point. Our SQL
> > server 2000 server (Standard) which is running only one instance currently
> > has 2G RAM. If I install 2005 (Standard) on the save server, that will
> > compete with 2000 for RAM.
> >
> > Bing
> >
> >
> >
> > "Gilberto Zampatti" wrote:
> > > Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> > > SP3.
> > > About a side-by-side installation of SQL Server 2005, i'm currently running
> > > on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> > > 2005 instances; since the installation i've never had a problem.
> > > The only important consideration in this case is: do i have sufficient RAM
> > > for both instances? Surely you'll need to configure appropriately Min memory
> > > and Max memory for each instance.
> > > More: currently i'm administering my SQL Server 2000 instances from SQL
> > > Server Management Studio.
> > > Gilberto Zampatti
> >
> > > "bing" wrote:
> >
> > > > Hi,
> >
> > > > I've read through the threads related to 2000-2005 upgrade I can find on
> > > > this newsgroup. From what I've gathered, seems there are the following three
> > > > ways to upgrade.
> >
> > > > 1. in place
> > > > 2. install a new instance that runs 2005 on the same database server
> > > > 3. Set up a different server and then install 2005 on it.
> >
> > > > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > > > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > > > for in place upgrade?
> >
> > > > For the rest two, I'm not very clear which one is better.
> >
> > > > If we do option 3, we need to make DNS changes for server IP/name move which
> > > > always doesn't happen right away in my environment. That would most likely
> > > > extend upgrade time. But the obvious benefit is in case something wrong
> > > > happens with the upgrade, I can have the original 2000 server to safely go
> > > > back to.
> >
> > > > For option 2, would a new 2005 instance have any negative impact on the sql
> > > > 2000 instance? Are them totally independent of each other? I need to know
> > > > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> >
> > > > I'd appreciate any insight or real world experience (better) regarding 2005
> > > > upgrade. Things don't always go the way as they are instructed in the doc.
> >
> > > > Thanks,
> >
> > > > Bing- Hide quoted text -
> >
> > - Show quoted text -
> Here is my experience in a nutshell - as much as I remember anyway. I
> just did a 2000 to 2005 upgrade for 8 production databases varying
> from a few hundred megs to 50 gigs.This approach with a new server
> allowed us to test and to hold cutting over until we were 100% sure
> everything was working. There are may ways to do this, but this how I
> did it....
> We built and configured a new 2005 server first. Here is the overview
> of the check list:
> 1. Build new server with network engineers.
> 2. Discuss best place to keep logfiles, databases, backups etc. Do
> appropriate sizing etc.
> 3. Decide what new services to use and get them configured and
> running. EX: We are not using analysis service.
> 4. Configure database mail.
> 5. Configure alerts and get backups going for system databases etc.
> 6. do a backup and restore from 2000 to 2005 and get the db backup and
> log maintenence jobs going. I did weekly stats update and alter index
> reorganize.
> 7. Created all windows, sql logins on the new box - we are mixed mode.
> 8. This allowed us to test the apps on the new server and permissions
> etc. The schema's can be troublesome. I dropped all users after
> restoring and then reapplied the permissions.
> 9.Here was my actual cutover checklist of things the SSIS package did
> a. take down apps/or web server during cutover
> b.backup 2000 databases to unc path
> c.resotore databases to new 2005 box from unc path.
> d.drop permissions (logins, schemas, roles, users)
> e. re-assign permissions as required.
> f.rebuild indexes
> g.set database compatibility level (90) for 2005
> h.re-point all applications to new SQL instance
> i.run backup and maintenence jobs to make sure all working.
> j.test and run other SSIS jobs
> k.detach old 2005 databases but leave on the server for awhile in case
> of issues.
> Kristina
>
Excellent! Thanks much. We're in a similar situation. For the last step
k, I think you meant 'detach old 2000 databases', right?
Bing|||On May 18, 11:11 am, bing <b...@.discussions.microsoft.com> wrote:
> "Kristina" wrote:
> > On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> > > Thanks for the response. RAM allocation is a very good point. Our SQL
> > > server 2000 server (Standard) which is running only one instance currently
> > > has 2G RAM. If I install 2005 (Standard) on the save server, that will
> > > compete with 2000 for RAM.
> > > Bing
> > > "Gilberto Zampatti" wrote:
> > > > Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> > > > SP3.
> > > > About a side-by-side installation of SQL Server 2005, i'm currently running
> > > > on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> > > > 2005 instances; since the installation i've never had a problem.
> > > > The only important consideration in this case is: do i have sufficient RAM
> > > > for both instances? Surely you'll need to configure appropriately Min memory
> > > > and Max memory for each instance.
> > > > More: currently i'm administering my SQL Server 2000 instances from SQL
> > > > Server Management Studio.
> > > > Gilberto Zampatti
> > > > "bing" wrote:
> > > > > Hi,
> > > > > I've read through the threads related to 2000-2005 upgrade I can find on
> > > > > this newsgroup. From what I've gathered, seems there are the following three
> > > > > ways to upgrade.
> > > > > 1. in place
> > > > > 2. install a new instance that runs 2005 on the same database server
> > > > > 3. Set up a different server and then install 2005 on it.
> > > > > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > > > > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > > > > for in place upgrade?
> > > > > For the rest two, I'm not very clear which one is better.
> > > > > If we do option 3, we need to make DNS changes for server IP/name move which
> > > > > always doesn't happen right away in my environment. That would most likely
> > > > > extend upgrade time. But the obvious benefit is in case something wrong
> > > > > happens with the upgrade, I can have the original 2000 server to safely go
> > > > > back to.
> > > > > For option 2, would a new 2005 instance have any negative impact on the sql
> > > > > 2000 instance? Are them totally independent of each other? I need to know
> > > > > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> > > > > I'd appreciate any insight or real world experience (better) regarding 2005
> > > > > upgrade. Things don't always go the way as they are instructed in the doc.
> > > > > Thanks,
> > > > > Bing- Hide quoted text -
> > > - Show quoted text -
> > Here is my experience in a nutshell - as much as I remember anyway. I
> > just did a 2000 to 2005 upgrade for 8 production databases varying
> > from a few hundred megs to 50 gigs.This approach with a new server
> > allowed us to test and to hold cutting over until we were 100% sure
> > everything was working. There are may ways to do this, but this how I
> > did it....
> > We built and configured a new 2005 server first. Here is the overview
> > of the check list:
> > 1. Build new server with network engineers.
> > 2. Discuss best place to keep logfiles, databases, backups etc. Do
> > appropriate sizing etc.
> > 3. Decide what new services to use and get them configured and
> > running. EX: We are not using analysis service.
> > 4. Configure database mail.
> > 5. Configure alerts and get backups going for system databases etc.
> > 6. do a backup and restore from 2000 to 2005 and get the db backup and
> > log maintenence jobs going. I did weekly stats update and alter index
> > reorganize.
> > 7. Created all windows, sql logins on the new box - we are mixed mode.
> > 8. This allowed us to test the apps on the new server and permissions
> > etc. The schema's can be troublesome. I dropped all users after
> > restoring and then reapplied the permissions.
> > 9.Here was my actual cutover checklist of things the SSIS package did
> > a. take down apps/or web server during cutover
> > b.backup 2000 databases to unc path
> > c.resotore databases to new 2005 box from unc path.
> > d.drop permissions (logins, schemas, roles, users)
> > e. re-assign permissions as required.
> > f.rebuild indexes
> > g.set database compatibility level (90) for 2005
> > h.re-point all applications to new SQL instance
> > i.run backup and maintenence jobs to make sure all working.
> > j.test and run other SSIS jobs
> > k.detach old 2005 databases but leave on the server for awhile in case
> > of issues.
> > Kristina
> Excellent! Thanks much. We're in a similar situation. For the last step
> k, I think you meant 'detach old 2000 databases', right?
> Bing- Hide quoted text -
> - Show quoted text -
yes, I am a poor writer.....it wasn't really that bad to do the
upgrade. I got the wrox press SQL 2005 Administration book and it
helped tons...
Good LUCK!|||"Kristina" wrote:
> On May 18, 11:11 am, bing <b...@.discussions.microsoft.com> wrote:
> > "Kristina" wrote:
> > > On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> > > > Thanks for the response. RAM allocation is a very good point. Our SQL
> > > > server 2000 server (Standard) which is running only one instance currently
> > > > has 2G RAM. If I install 2005 (Standard) on the save server, that will
> > > > compete with 2000 for RAM.
> >
> > > > Bing
> >
> > > > "Gilberto Zampatti" wrote:
> > > > > Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> > > > > SP3.
> > > > > About a side-by-side installation of SQL Server 2005, i'm currently running
> > > > > on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> > > > > 2005 instances; since the installation i've never had a problem.
> > > > > The only important consideration in this case is: do i have sufficient RAM
> > > > > for both instances? Surely you'll need to configure appropriately Min memory
> > > > > and Max memory for each instance.
> > > > > More: currently i'm administering my SQL Server 2000 instances from SQL
> > > > > Server Management Studio.
> > > > > Gilberto Zampatti
> >
> > > > > "bing" wrote:
> >
> > > > > > Hi,
> >
> > > > > > I've read through the threads related to 2000-2005 upgrade I can find on
> > > > > > this newsgroup. From what I've gathered, seems there are the following three
> > > > > > ways to upgrade.
> >
> > > > > > 1. in place
> > > > > > 2. install a new instance that runs 2005 on the same database server
> > > > > > 3. Set up a different server and then install 2005 on it.
> >
> > > > > > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > > > > > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > > > > > for in place upgrade?
> >
> > > > > > For the rest two, I'm not very clear which one is better.
> >
> > > > > > If we do option 3, we need to make DNS changes for server IP/name move which
> > > > > > always doesn't happen right away in my environment. That would most likely
> > > > > > extend upgrade time. But the obvious benefit is in case something wrong
> > > > > > happens with the upgrade, I can have the original 2000 server to safely go
> > > > > > back to.
> >
> > > > > > For option 2, would a new 2005 instance have any negative impact on the sql
> > > > > > 2000 instance? Are them totally independent of each other? I need to know
> > > > > > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> >
> > > > > > I'd appreciate any insight or real world experience (better) regarding 2005
> > > > > > upgrade. Things don't always go the way as they are instructed in the doc.
> >
> > > > > > Thanks,
> >
> > > > > > Bing- Hide quoted text -
> >
> > > > - Show quoted text -
> >
> > > Here is my experience in a nutshell - as much as I remember anyway. I
> > > just did a 2000 to 2005 upgrade for 8 production databases varying
> > > from a few hundred megs to 50 gigs.This approach with a new server
> > > allowed us to test and to hold cutting over until we were 100% sure
> > > everything was working. There are may ways to do this, but this how I
> > > did it....
> >
> > > We built and configured a new 2005 server first. Here is the overview
> > > of the check list:
> > > 1. Build new server with network engineers.
> > > 2. Discuss best place to keep logfiles, databases, backups etc. Do
> > > appropriate sizing etc.
> > > 3. Decide what new services to use and get them configured and
> > > running. EX: We are not using analysis service.
> > > 4. Configure database mail.
> > > 5. Configure alerts and get backups going for system databases etc.
> > > 6. do a backup and restore from 2000 to 2005 and get the db backup and
> > > log maintenence jobs going. I did weekly stats update and alter index
> > > reorganize.
> > > 7. Created all windows, sql logins on the new box - we are mixed mode.
> > > 8. This allowed us to test the apps on the new server and permissions
> > > etc. The schema's can be troublesome. I dropped all users after
> > > restoring and then reapplied the permissions.
> > > 9.Here was my actual cutover checklist of things the SSIS package did
> > > a. take down apps/or web server during cutover
> > > b.backup 2000 databases to unc path
> > > c.resotore databases to new 2005 box from unc path.
> > > d.drop permissions (logins, schemas, roles, users)
> > > e. re-assign permissions as required.
> > > f.rebuild indexes
> > > g.set database compatibility level (90) for 2005
> > > h.re-point all applications to new SQL instance
> > > i.run backup and maintenence jobs to make sure all working.
> > > j.test and run other SSIS jobs
> > > k.detach old 2005 databases but leave on the server for awhile in case
> > > of issues.
> >
> > > Kristina
> >
> > Excellent! Thanks much. We're in a similar situation. For the last step
> > k, I think you meant 'detach old 2000 databases', right?
> >
> > Bing- Hide quoted text -
> >
> > - Show quoted text -
> yes, I am a poor writer.....it wasn't really that bad to do the
> upgrade. I got the wrox press SQL 2005 Administration book and it
> helped tons...
> Good LUCK!
>
Glad to hear it isn't that bad. Thanks again, Kristina.
Bing
pen: Operating system error 2(The system cannot find the file specified.) occurred while creating or opening file 'C:\PROGRAM FILES\HYSTER SUITE\MSDE\Data\MSSQL$HS2000\Data\Hyster.mdf'. Diagnose and correct the operating system error, and retry the operation.