The Migration Roadmap so far ……..
- Planning the migration
- Designing architecture migration
- Implementing schema migration
- Implementing data migration
- Implementing application migration
- Implementing operation migration
- Validating the migration
This is the second installment for best practices for migrating to SAP SYBASE ASE server. Regardless of which database vendor you are moving from, the steps outlined below will form the overall guide for our talk. We are now onto the second step of designing an architecture migration. We will also target our talk mainly to the nonSAP Applications. This is simply because the SAP Application migration process is covered under the well understood, well rehearsed SAP Service Package called OS/DB migration. I’ll refer to this Service Package where appropriate but let us assume for this talk we are focusing on nonSAP Applications. Some of the information in this talk applies to both SAP and nonSAP migrations.
Architecting for the migration involves two areas of focus: first we need to architect or blueprint the target ASE Database server. Secondly, the topic of architecting the “how” of the migration cutover process will be covered in Step 7: Validating the migration.
A layman’s guide to the SAP Sybase ASE database server
To my Readers who are familiar with the internals of the SAP Sybase database server, please feel free to skip over this section as it designed to give everybody a starting point for the designing and configuration of the target ASE server.
The internal structure of a SAP Sybase ASE server is comprised of many databases on a single server instance. Typically a single server instance is implemented on a single hardware server instance. With respect to the type of databases there are two groups: system databases and user databases. The system databases are installed by default and are responsible for base functionality of the ASE server as well as supporting the various options that come with the ASE server. The user databases are what we create to hold our data tables and procedures. There can be many combinations and designs for the user databases. This will be discussed as part of the blueprint for the ASE server. System databases that are installed by default are:
- master database: responsible for users logging into the ASE server as well as holding metadata that describes the configuration of the user databases and general parameters.
- tempdb database: temporary storage of user created temp tables and worktables used for optimizing queries.
- model database: used as a seed database to create user databases and the tempdb database upon startup.
- sybsystemprocs database: holds all system-wide stored procedures.
Blueprinting your ASE server
For SAP Applications that migrate to the SAP Sybase ASE platform there are recommended minimums for server configuration and the internal layout of the user databases. This has all been designed to work best in an SAP environment. This is all part of the SAP Services Package OS/DB Migration Services.
For nonSAP Custom Applications we need to do this design work ourselves. For example, if we were to have a Microsoft SQL server as a source then the internal architecture of the Sybase database would be relatively straightforward in that the SAP Sybase
Database server would mimic the Microsoft SQL server. This would be a starting point and we can further architect from this point as we would want to take advantage of the nuances of the SAP Sybase ASE platform.
For migrating from Oracle to SAP Sybase platforms the decision points for blueprinting our database server introduce more options. In layman’s terms, Oracle grouping or ownership is based upon a concept known as a “schema.” Objects as tables
and procedures are grouped in schemas and these schemas are owned by logins or users to the Oracle server. The internal
structure of an Oracle database is a single database with one or many schemas residing in the single database. Conversely,
Microsoft and SAP Sybase architecture is many databases interacting with many schemas.
Basically we can start the blueprinting process moving from Oracle to the SAP Sybase ASE server with two options:
- Every Oracle schema translates to a single SAP Sybase user database where the database name becomes the former schema name. The database and object owner is known as “dbo.” This allows us to make small identifiable changes to the underlyingclient code. As an example, for a simple select statement the syntax would be: “select * from <schema>.dbo.<table>”.
- Mimic the existing Oracle server architecture and create a single SAP Sybase database with all schemas being present and with the schema names translating to object (tables and procedures) owner names. As an example, for a simple select statement the syntax would be: “select * from <ORA server Name>.<schema>.<table>”.
For those systems that need to be architected further, the server blueprint is a combination of the two blueprints listed previously. Decision templates exist to lead the architecture design based on grouping “like schema” into their own user database and separating schemas into separate databases based on functionality, usability, supportability and activity. For example if one had 25 very active schemas and 75 non-active schemas then a draft cut of the blueprint of the ASE server might be to separate all active schemas into their own database and group all non-active schemas into 1 database. In total for this draft architecture we would have a total of 25 + 1 or 26 user databases. As in all decisions made at this level, testing is critical to either keeping or further refining the number and skew of the user databases. You should build into your project the option of time to refine the
original architecture as you become more familiar with the ASE platform.
The SAP Sybase server has a concept known as temporary databases or scratchpad databases. The ystem uses these databases for solving queries, building hidden tables, etc. We start with 1 tempdb database and epending upon the number of concurrent processing we can increase the number of tempdb databases. It is extremely simple to add and remove any number of tempdb databases. Start with 50 active connections to one tempdb database being defined (assuming CPUs at 20 or above). SAP Sybase has tools that tell us when we need to add another tempdb instance.
The last question is related to the hardware; How much RAM, CPU, Hard Disk do I configure for? This is perhaps one of the most
nebulous configuration points. In a perfect world we could configure the hardware based on testing and it is readily assumed that the target SAP Sybase database server would consume less CPU, RAM and Hard Disk space. Past configurations from Oracle to Sybase have reduced physical dependency from 50 to 80%. This is a wide margin and one size does not sit all. The best advice in this area is to start with the same hardware and number of CPU, RAM and Hard Disk. Once a Pilot Build is done and stress testing is complete then the true picture of server hardware can be arrived at. The savings in hardware is going to be specific to your application dynamics.
Clearly moving to a virtual environment as part of the migration has its advantages. In these situations the server hardware has been oversized to accommodate multiple ASE server instances. What one saves or gives back to the virtual environment from one ASE server can be used by another ASE server.
This phase, Designing architecture migration, is complete. We have the starting assumptions for the target hardware, software and a plan for building the SAP Sybase ASE server. We will assume that at the conclusion of this phase you have installed the ASE software on the hardware and created the user databases based on schemas found. We have our environment ready to populate.
That’s it for now, next blog I will focus on the next step in our migration high-level steps: Implementing schema migration. Moving objects or schema from Oracle or Microsoft (or others) to SAP Sybase can be automated using the SAP Sybase tool called PowerDesigner and we will introduce this tool in the next blog.
