Skip to Content

My 2nd Sybase ASE migration experience

When I first tried to do a test migration from a Windows 2008 R2 x64/SQL Server 2008 R2 x64 System to Windows 2008 R2/Sybase ASE 15.7 x64 for our RDS Qualification, I wrote the blog My first Sybase ASE migration experience.

At that time, this experience did lots of cofusions on my side and on community side.

Some partners and customers in Turkey asked me if the data growth is real when you migrate from SQL Server to Sybase ASE.

The answer is important, because there are 5 customers (2 are Holding, means lots of systems and sub-companies) who are waiting to migrate to Sybase ASE.

That’s why, as a SAP Partner, we discussed this issue with SAP Team. Jan Stallkamp helped me to clarify cloudy parts of this issue.

Yesterday I did my second migration from a 350G database of same source into Sybase ASE to see a more realistic result.

Migration Landscape

Source System

Target System

OS Version

Windows 2008 R2 SP1 x64

Windows 2008 R2 SP1 x64

DB Version

SQL Server 2008 R2 (10.50.1702) x64

Sybase ASE x64

SAP Solution



SP Level

SAPKB70209, SAPKA70209

SAPKB70209, SAPKA70209


4 VCPU (2.8GHz)

4 VCPU (2.8GHz)


36 GB

36 GB

DB Size

338,4 GB

346,5 GB (2,39% growth)

Here are the DB02 information for both Source and Target DBs.

Source System Target System


The result is a bit different than the previous migration as you can see.

So, lets talk about what is actually changed and made this difference.

Whas has changed?

1. DB size for Source System

We did the first migration with a quite small SQL DB with 54 GB in size. As you can imagine, this is a very emtpy system DB size and will never reflect a customer system.

So, this time I tried to do the migration with a ~ 350 GB system. For this, I copied an existing system client into several clients (10 actually 🙂 )

So, now we can say that it is nearly a customer system (test or development may be ha?)

2. New Installation Media

After discussing the issues in first migration with Jan, we noticed that there are issues with SAP Standart Tables using LOBs.

Sybase ASE can store LOBs either on the normal data pages (on-row) or on separate pages (off-row). The threshold we have implemented to switch between this two ways to store data was set by SAPInst to 2000 for your system. Unfortunately the mentioned tables contain a lot of LOBs that are larger than this threshold but not ‘really large’. This results in bad space consumption.

SAP changed the SAP installer to have better settings for this kind of tables also put this feature into Sybase ASE with ESD#02.

To get advantage of in-row-LOB compression you will need to have in place before the load starts (or do reorgs after the system is migrated).

See SAP Note 1773862 about

Another Issue was about the empty tables. As my system was quite small the overall size is significantly impacted by the size of empty tables. There are a lot of database tables in an SAP system that are not used for your type of operations. But creating an empty table on disk costs some amount of space.

Therefore ASE development put a feature (and this is delivered with 15.7 ESD#2) to not create empty on disk but only store them in the system catalogs. Creating a table will happen as soon as the first write operation happens.

Used Installation Medias


3. Interpretation of DB02 (or DBACOCKPIT) for Sybase ASE

This is the easiest part. Because it is possible to misunderstand the DB02 values if you’re not familiar with ASE (As I was).

In the first screen of DBACOCKPIT, under Space > Databases, the Database Size (MB) is showing the full size of Datafiles (whether allocated or not) plus the Log space.

In my system, this value is 419.840 MB (419,8 GB).


First you’ve to remove the log space size. You can see the log device and data device sizes in the same screen.


Here remove 10 GB from 419 GB.

You also have to remove the unused space which is 63 GB.

So, resulting size is 346,5 GB which is almost same as SQL Server.


Sybase ASE provides the same data compression as Microsoft SQL Server 2008 R2.

So, migrating from any other database to Sybase ASE will give you the same reduced DB Size as SQL Server.

I want to thank Jan Stallkamp again for his support during this tests.

You must be Logged on to comment or reply to a post.
  • Hi Hüseyin.

    Thanks for sharing your experiences with everyone here in the community. Let me add some comments from my side:

    • Interpretation of DB size in DBA Cockpit: There are two ways to look at 'DB size'. One is to look at the size of storage you need just for your data, one is looking at how much space you actually allocate on disk for the whole system (including reserved but not yet used space, log space...). The second way is used by Sybase ASE-tools like sp_helpdb and therefore I used this when I developed this screen for the DBA Cockpit. But as it turned out that many people are more thinking in the concept of 'how much data space is used' this leads to misunderstandings. So now I've rewritten the screen in the DBA Cockpit and with the next SP (for 7.02 this should be SP13) this screen will show the information in a better way.
    • The 'deferred table creation' for empty tables was introduced with ESD#2 but we had to deactivate it in the SAP application context. I expect this to be enabled for ESD#4. So you can expect some savings in the near future.

    Regarding the LOB-handling I would like to highlight that there are two features that have been added: First we introduced better defaults for the threshold that defines which LOBs are stored on-row and which are stored off-row. And in addition we got the on-row LOB compression.

    I think the results you have seen are looking good now and this shows the power of the ASE compression algorithms introduced with 15.7. But as I said during my presentation at SAP TechEd: From development perspective there is no 'good' performance/TCO/availability/... We are always looking on improvements and for example the deferred table creation will be enabled soon.

    Once again thanks for your feedback! It was a pleasure to meet you in Madrid and discuss your first impressions with Sybase ASE.

    Best regards,


  • Hey Huseyin,

    I'm doing a similar thing but am getting stuck in the middle of the migration.

    I have three questions:

    1. Did you have to install ECC on sybase on the target host in order to receive data from the source? (that's what I did)

    2. I am trying to migrate an ECC/IDES on Oracle to Sybase but the migration has taken over 2 days and I am still on the import abap stage!!

    3. The database has roughly doubled!! I know I can reclaim it later but this is some serious issue, especially for people with larger databases and running on virtual environments you can't really reclaim allocated storage space unfortunately (We use vCenter and ESXi 5.0).

    • Hi,

      Here is my comments and answers to your questions. Hope they help you to resolve the issues.

      1. Migration is 2 steps process. First you're exporting the source system with SAP Installation Master (Now may be you can use Software Provisioning Manager. Plz check the compatibility). Then on the terget system, you're installing a new system with Installation Master, but by using System Copy > Target System option as I mentioned in my first Blog.

      2. Not sure if IDES is supported for Export/Import. But for normally it must not take so long.

      3. This reflects my first attempts results. Please check my first and then second blog to see how I did solve this problem. Briefly, by using updated ASE DB and latest installation master and kernel.


  • Hello Huseyin,

    Nice follow-up on your first experience! I've had the same experience with a freshly installed WAS ABAP and WAS Java. There just isn't always a system around that reflects a real customer system to test these things with. In the mean time I've setup a few new systems based on Sybase ASE and am growing more enthusiastic about the database each time. I'm still waiting on some features like OS authentication and VSS integration though....

    Kindest regards, Wilbert