downgrade to sql 2000

[Former Member]

Hi,

We are doing a system migration from one hardware platform to another. We do this by installing a new SAP server + SQL server on the new hardware, detaching the data from the source system, attaching on the target system and running STM.

Source system setup is: Win2003, SQL2000, SAP ECC 6.0

Target system setup is: Win2003, SQL2005, SAP ECC 6.0 <-- SQL server 2005 was erroneously chosen by us

Now, the question is: How can we downgrade the target system to SQL 2000? Do we have to re-install the system all over, or is it sufficient to delete SQL 2005 and install SQL 2000?

Has anyone tried this?

Go-live is Friday, so we are in a hurry

Thanks

Thomas

[Former Member · Accepted solution]

downgrade the target system to SQL 2000? its not recommanded and as per me its not supported.

Best way is you can go with re-install the system all over.

Regards,

Nikunj Thaker.

[Former Member · Accepted solution]

Hi,

Do you know for a fact that removing SQL2005 and installing SQL 2000 will not work, or are you just stating that a full system re-install is the best way to go?

Thanks

Thomas

[Former Member · Accepted solution]

> Do you know for a fact that removing SQL2005 and installing SQL 2000 will not work,

No. As i told you ealier its not recommanded i did not tried that.

>or are you just stating that a full system re-install is the best way to go?

I am just stating becuase its good way to do.

Regards,

Nikunj Thaker.

[Former Member · Accepted solution]

Hi Thomas,

SQL Server 2005 does some changes to the database files, meaning you cannot downgrade the database because SQL Server 2000 is not aware of theses changes and can't undo them. You can reinstall SQL Server 2000 by using the last full backup from your SQL Server 2000 instance. But the drawback is that all DML operations that have been performed while the instance was on SQL Server 2005 are lost.

Sven

[Former Member · Accepted solution]

Hi Sven,

We would indeed take the database files from the source system in a "fresh" version from the SQL 2000 installation there and re-transfer them to the target system once again. Hence, the database files themselves have not been in touch with the SQL 2005 installation (as this has been removed from the target system altogether).

Thanks for your input!

Thomas

[Former Member · Accepted solution]

Hi,

Let me clarify the question:

Source system has SQL 2000 and SAP ECC 6.0 (system is live here)

Target system has SQL 2005 and SAP ECC 6.0 (there is no data here yet, just the database installation)

In the weekend, we are going to detach the database files from the source system and transfer them to the target system. As we have realised, the SQL 2005 installation in the target system is wrong and needs to be SQL 2000.

Hence, the question is if this plan is possible:

1) Remove SQL 2005 from the target system

2) Installl SQL 2000 in the target system

3) Detach data files from the source system

4) Attach data files in the target system

I am not certain that the SAP system in the target system can connect to the new database, without further changes? Can it do that after the four steps above?

Thanks

Thomas

[markus_doehr2 · Accepted solution]

> In the weekend, we are going to detach the database files from the source system and transfer them to the target system. As we have realised, the SQL 2005 installation in the target system is wrong and needs to be SQL 2000.

Can you tell me where you did "determine" that SQL Server 2005 is wrong?

Markus

[Former Member · Accepted solution]

Hi,

Thanks for your interest.

Yes. First of all SQL 2005 is 'wrong' because the source system is on collation "bin" whereas the target system must be on collation "bin2" if it is an SQL server 2005. The source systems cannot have "bin2" installed because it will require downtime in the source system and we can't have that.

We have done a test where we run the target system SQL 2005 with collation "bin" and then attach the database. That works fine, apart from loads of messages coming out of transaction SICK:

DB CHECK Wrong Database collation. Perform SQL2005 after upgrade steps. Please see note 126973

DB CHECK DB CHECK DB CHECK DB CHECK DB CHECK DB CHECK DB CHECK DB CHECK DB CHECK DB CHECK

Severe problems were detected during initial system check.

Please, do not use that system before fixing these problems.

I have checked the mentioned note, and also notes 600027, 62988, 126973, 799058, 924288 and 1291861. None of them seem to fix the problem. So we decided to forget about the SQL server 2005 for the weekend and instead go for a 1:1 correlation between source and target systems, and then plan for a SQL 2005 upgrade later.

What are your thoughts? Can SICK be fixed?

[markus_doehr2 · Accepted solution]

I would upgrade the source system to SQL Server 2005.

SQL Sever 2000 is - according to PAM - not recommended any more for production installations.

On top you should really consider upgrading to 64bit. If this is a new machine it can for sure run a 64bit OS. 32bit for such a huge system as ERP is also deprecated.

Markus

[Former Member · Accepted solution]

Hi,

Point is that there is no time to upgrade the source system. The hardware migration must happen this weekend and there is no downtime allowed on the source system.

Hence, the main point is to find a safe migration-path for the weekend and then think about an upgrade later.

Thanks

Thomas

[Former Member · Accepted solution]

Hence, the question is if this plan is possible:
1) Remove SQL 2005 from the target system
2) Installl SQL 2000 in the target system
3) Detach data files from the source system
4) Attach data files in the target system
I am not certain that the SAP system in the target system can connect to the new database, without further changes? Can it do that after the four steps above?

Additionally you have to recreate the logins (master) and possibly the jobs (msdb) otherwise you won't be able to connect. Check with Note 1294762 - SCHEMA4SAP.VBS and Note 151603 - Copying an SQL Server database.

Sven

[Former Member · Accepted solution]

Hi,

I did as planned:

1) Detach database

2) Remove SQL 2005

3) Install SQL 2000 + patches

4) Copy database files from source system (SQL 2000)

5) Attach database files

6) Done (source and target systems have the same SAP SID)

I also checked note 1294762 as recommended, but it was not needed. Thanks for the input though - I used the note on another customer to solve DB login issues. )

Regards,

Thomas