Import from Sybase Adaptive Server Ver 16 to Adaptive Server Ver 15.7
I’m currently in the process of upgrading server OS’s from WIN2003 to WIN2008 and need to purchase a version of sybase that is supported on WIN2008 R2 64bit. I want to ensure I can import a Sybase Export file from a Sybase Version 16 DBMS into a Sybase 15 version. My customers are on Sybase Version 15. Would Sybase Version 16 support a version of Sybase 15 as a target delivery format?
Depends on whether you are talking about a database dump file (you can load a 15.x dump into a 16.x server, but not the other way around), or a bcp output file (which can go either way, but contains the data for just a single table).
-bret
So, Bret - why is that so? I know going from 12.5 to 15 you can't (page files or something as I recall). For many background information what is the underlying reason that I can't go from a ASE 16 export file and import it to a ASE 15.7? Thanks
Hi Paul,
hm. "page file" sounds like a SQL Anywhere concept, rather than an ASE concept. Are you sure you are asking about ASE?
Still not quite sure what you are meaning by an "export file".
ASE dump files are a full copy of the database. There are often changes to system tables during major version upgrades. The higher version of ASE knows what it has to modify to upgrade a lower version format to a higher one (well, within limits*), but the lower version has no way of knowing what changes will be made in the future, so doesn't know what it would have to do to downgrade. In 15.x, we had a feature to downgrade a database while it was still on the higher version, so you could downgrade a database and then dump it. Engineering decided not to provide something similar for 16.0.
*There are limits to how far back this is supported. If you are on something older than 12.5.4, you should first upgrade to the most recent 12.5.x rollup, and then from there to 15.x /16.x.
Exports of a single table or view's data through bcp are version-independent.
-bret
Paul
Can you elaborate on what you are trying to export / import ?
Table(s) OR whole database(s) ?
Dumps (backups) are binary files for a whole database. Dumps are backward compatible like most of the software going from lower version to higher but not the other way round. This is usually because of underlying design/architecture changes in the newer/later version.
Tables contents can be exported/imported by a utility program BCP as Bret pointed out above. And using BCP repeatedly for all tables you can re-build a new database too.
BCP in character mode is neutral to ASE versions and OS platforms.
HTH
Avinash
Avinash,
Thanks for the information. Some of my reply back to Bret answers you questions.
Re: Can you elaborate on what you are trying to export / import ?
Table(s) OR whole database(s) ?
It's the whole database "dump database <my database> to 'q:\data\delivery\my_database.dmp'
Thanks for the other info
Paul
Hey Bret,
Ya, I was not sure about the 12.5.4 to Sybase 15.0.3 - I know that was not possible but the reason forgoes me at this time. I thought it was something with the "page file" but was not sure and thought it may apply to the Sybase ASE 16.0 going to Sybase ASE 15.7.
RE: Export File - it's the dump file (many tables including system tables) using the dump database command.
Anyway, we have two boxes to support the Sybase Version 12.5.4 and Sybase 15.0.3 (maybe .5) database exports we deliver to our customer. They are both on WIN2003 Servers. We are good with that. However we are going to a WIN2008 R2 (64 bit) server and want to get rid of the Sybase 15.0.3 installed on a WIN2003 Server.
Question: Looks like I have to keep that server in order to support Sybase 15.0.3?
Ideally, I would like to support both the Sybase 15.0.3 and Sybase 16 on ONE Server when it comes to dumping the database out and delivering it.
So, what I gather in your message - if I'm going to support my customers installation of Sybase 16 on WIN2008 R2 64 bit I need to have a Sybase 16 "dump database" file of that Database to deliver to the customer so that he/she can import that dump file back into their system which is Sybase 16 running on a WIN2008 R2 (64 bit) Server.
Would you agree with the above statement?
Thanks
Paul
Hello Paul,
Export file.. you maybe a former Oracle user? 😉
Summarizing, you can load your ASE 15.0.3 dump into an ASE 16.0 but you cannot load an ASE 16.0 dump into your ASE 15.0.3.
Btw, just a request.. 🙂 In the future, could you please use the action "Start a discussion" to submit a question? You probably will have more chances to get replies as it could be interesting for other persons 😉
Cheers
Cris
All,
Thanks for all who responded. My answer has been answered. Basically I come away with the following:
* To put it simple I can import up to a new version ASE 15 -> ASE 16 but I can't go from a higher into a lower version of Sybase ASE.
In order to support my customer who is also in transition from Sybase 15 to Sybase 16 I'll have to maintain two Sybase Servers running Sybase 15 and one running Sybase 16.
Cristina - RE: Oracle - yes - I have to deliver Oracle export files for another customer as well. My terminology crosses both DBMS's. RE: "Start a discussion" - roger that note taken - first time I posted here.
===============================
| However, that leads to another Question |
===============================
Questions:
---------------
1. Can I Load a database from a WIN2008R2 64bit Sybase ASE Version 15.7 on to a WIN2003 32bit Sybase ASE Version 15.0.3?
2. Would that still be considered a lower into a higher Sybase Version and can not be done? (Plus 64bit going to a 32bit)
Thanks
Paul
The answer is still the same - you cannot go from an newer version to an older release with dump/load.
64 vs. 32-bit does not matter with ASE. This is not coded in the database.
Going from one Windows release to another (when done from older release of ASE to newer) is not an issue as it is considered the same OS/Hardware. Going to another platform (e.g. Solaris) can be handled by the cross-platform dump and load features of ASE.
You are going to have to look at BCP out/in or Component Integration Services to move data from a newer ASE release to an older ASE release. This type of move can also help take care of page size changes, sort orders and character sets in case you want to take advantage of newer ASE capabilities (e.g. UTF-8) in your application..
To be honest, however, you should not be supporting or endorsing ASE 15.0.3. It is EOL and not supported by SAP any longer. Your customer should be encouraged to move to a supported release.
Chris
Chris,
That answers my other question about Sybase. Thanks for the response!
Yes, our customer wants to get off Sybase 15.0.3 but it is a slow process for them.
Thanks Again
Paul
Being involved in a kin upgrade process....
I'd suggest the following:
If you want to have both ASE 1503 and ASE XXX versions around in sync - ask your SAP representative for the replication server quote. If your servers are not large and the transaction volume not too high you may be able to make decisions at greater ease with both versions up and running and in-sync all the time (less pain cutting the umbilical cord, so to say).
If you want to be able to go to-fro between the versions with a possibility to fall back but without using rep server:
I'd suggest going for ASE 15.7 SPxxx rather than ASE 16. Fall back procedure from ASE 15.7 SPxxx to ASE 1503 is possible (although it is a downgrade procedure rather than simple dump/load which cannot go to a lower version, as Chris has noted). If you pass the ASE157 SP100 watermark, your downgrade will be two phase (SPxxx to SP100 and than SP100 to ASE 1503).
As a side note to SAP listeners - it would have been pretty nice if SAP has thought about a special license quote to ASE customers that would allow them purchase a rep server license for the purpose of performing upgrades. It is really a pity that ASE customers are not made the best upgrade possibility available at reasonable cost. Companies run unnecessary risk because the RS licenses are pricey and often using rep server in the upgrade process is dismissed due to the high cost of involving the product in the upgrade project. Can anyone from SAP side pick up this thread and come with something constructive?
Thanks,
Andrew