http://goo.gl/EmKxy0

Archive

Posts Tagged ‘Migration’

Migrating SAP Sybase ASE from AIX to Linux

May 1st, 2013 No comments

Always consider to migrate the Development environment first , then UAT. Before moving to production Perform Regression testing on UAT enviornment.

Please consider to create the script to perform update stats,xp_postload(drop and re create index) for each and every database.

Steps for an ASE Database( You can repeat same steps for other databases) :

Step 1: Run the consistency checks in ASE database in Source (AIX) environment, to make sure that everything is fine.

Step 2: Put the database in single user mode.

Step3: Make sure there is no user activity on the Source Database .

Step 4: Run the sp_flushstats in the database.

Step 5: Take the backup of the database in Source (AIX) environment.

Step 6: Ftp the Files to Target environment. (AIX to Linux)

Step 7: Create and build the dataserver and databases in target Linux environment with exactly same configuration.
You might require to change some of the config param in Linux environment for performance point of view. ( Lets not discuss it here, as it is out of context).

Step 8: Also migrate the Login, roles from source server to target server

Step 9: Load the database in Linux environment.
(If there were user activity during dump process, load will be fail.)

Step 10: Online the database. If the target ASE version is new with source, It will also perform upgrade in this step.

Step 11:  Fix the corrupt indexes using the xp_postload. If the Database size is more than 20G, try drop and re-create index , in this case xp_postload would not be effective.

Step 12: Update the stats on all tables.

Step 13:  If there is replication setup in your environment, please setup replication after that.

Issue Faced:

1. If there is any user online during backup process, your load will fail( in the step for cross platform conversion).

2. After online database, we seen the -ve values in sp_helpdb output for few databases. There are two ways to fix this :

i) Try to run dbcc

dbcc usedextents(<DB name or DB ID>, 0, 1, 1)

ii) Use the Traceflag  7408 and 7409 in Run Server file and reboot the instance. It will not take much time as compare first option.

Traceflag 7408 : Force the server to scan *log segment* allocation pages; to recalculate free log space rather than use saved counts at boot time.
Traceflag 7409 : Force the server to scan *data* segment allocation pages; to recalculate free data page space rather than use saved counts at boot time.

Please let me know if you are planning for migration and need any assistance.

ASE 15 Migration Study: Why you should handle prepared statements with great care.

July 30th, 2012 No comments

I have been involved for the past two months in analyzing migration problems of two large local ASE sites.  I decided to share with you the things discovered during the failed ASE 15 migration analysis so that if you happen to be in a similar situation you may discover the way out with less pains.

For these customers, migration to ASE 15.0- ASE 15.5 has been a painful fiasco for two consecutive years.  Cases have been opened.   Professional Services have been sent on site.  A lot of work have been done on rethinking and rewriting code for the new optimizer whims.  Tears, money, and what not shed all through the process.

The truth is, Sybase TS has been telling us  for years that we have bad code, and we – as customers or support teams – were each time infuriated by the insolence of telling us this.  I cannot say that TS has been completely wrong. I can say, however, that were we thinking more WHAT is so peculiar about our code rather than WHY are we told that our code sucks we might have spared ourselves a lot of pain.

I will not write you a detailed report on what we have found here in the blog pages – it will require a lot of pyrotechnics to make things legible here.  Rather, I attach you the report of the study.  You may download it and read at your leisure.   I think it is worth the pains.  Who knows, may be it will solve migration problems for more customers out there.  Local customers were not SO peculiar after all.

Here is the link:  Migration to ASE 15 – 2 Case Studies Involving Prepared Statements.

For those who have little time reading this, let me just warn:  if you use prepared statements in your application code – awares or unawares – beware.  You may be paying very high penalty for this.  Especially in ASE 15 that has been made to work fast – sometimes very fast.  The penalty may be so high that you will consistently fail migrating your old ASE 12.5.x servers to ASE 15 without knowing that the solution is so close.

Here a preview of some data:

Have fun reading this.  I have had a lot of fun digging up the roots of the failed migrations (using my own tools, to be sure, and writing new ones along the way).

If you have any questions – be my guest.

Cheerfully,

A.T.M.