Database Technology Trends

Overview

Back in the 90’s, a group of German engineers put together the world’s first grid computing network. When putting together this network, they used over 100 PCs running on the first version of the Linux operating system. It was a great success, and everybody called it the dawn of a new technology that would change the computing world forever.

What these engineers didn’t understand was how database engines worked at the time. They also didn’t realize they were setting important trends in hardware development. The database engines were calling for Massive Parallel Processing (MPP) hardware systems that offered dozens of CPUs on one single server platform.

Database engines have evolved over the years. Sybase’s database engine, ASE Cluster Edition, has propelled its ASE technology to the next level. For many DBA’s, the new technology will be uncharted territory. Let’s look at some specifics to help you master the technology, and make it accommodate to your business and current computer systems.

Benefits of Sybase ASE Cluster Edition

For more than 2 decades, Sybase DBAs worked with the principle that every database belongs to one and only one Sybase server instance. Sybase ASE Cluster Edition tears down these limitations, by making it possible to share a single database with up to 32 Sybase instances on as many server nodes.

The benefits of having multiple instance accessing and writing to the same database are large in scale, and offer ease of use and flexibility:

• Built in high availability with instant failover from one instance to another. Applications can take advantage of server side failover without losing connectivity with minor changes to the client library.

• Consolidating many underutilized Sybase ASE instances into a Sybase cluster will ease the management burdens and provide instant high availability to these smaller servers.

• If you’re already using standby servers for your most critical applications, you can reduce the number of standby servers by moving these applications into a cluster environment. For example: instead of having 3 standby servers to protect 3 individual applications, you can move the 3 applications into a 4 node Sybase cluster and reduce the standby server to 1 node.

Avoiding Risks When Upgrading Your Existing Database Server

To take advantage of the benefits Sybase’s ASE Cluster Edition provides, you need to upgrade your current Sybase ASE server to the Sybase ASE Cluster Edition release. Before you jump to the installation CD, here’s a word of caution. Performing a heavy lift on a production system has many associated risks. You have to exercise due diligence to mitigate these risks to a minimum.

The major key success factors for this server upgrade are a rock solid plan and endless testing for this server upgrade. This is no different than any other major Sybase ASE upgrade. Another important factor is to give yourself enough time to do the job correctly, so that you will have a successful upgrade. 

Choosing Your Upgrade Options

To upgrade your existing Sybase ASE server to the ASE Cluster Edition, you have 2 upgrade options available. This article focuses on the in-place upgrade option and gives you the exact steps to upgrade to ASE Cluster Edition, while remaining on your existing hardware. There are many reasons why moving to new cluster hardware is not an option at all. Budget constraints are one; inflexible client access configurations are another reason.

Sybase makes it easy for you to upgrade from an existing Sybase ASE server to a Sybase ASE Cluster Edition without abandoning your existing hardware.

Move the database to a new ASE Cluster Edition installation.

This option requires you have spare hardware available, and offers the most benefits for your applications. If your application has a 24/7 requirement with no downtime option, installing a new cluster in combination with up-to-the-last transaction replication via Sybase Replication Server is your only option.

With great benefits come great requirements. In order to create a minimally intrusive upgrade with new hardware, all applications must be able to switch their database server access. This might be not an issue for internal clients, but it may be a problem for remote access clients. If you have remote access clients, it’s one more thing to think about and plan for resolution.

The basic steps for a cross server migration are:

• Create a new Sybase ASE Cluster Edition server on spare hardware.
• Export and load the user logins from the old database server to the new cluster.
• Dump and load your database(s) from your existing server to the cluster.
  With the XPDL technology, you can cross OS platform dump and load databases. Please reference the Sybase ASE Cluster Edition Installation manual for availability and limitations.

• (optional step) With Sybase Replication Server, the transactions since the last dump and load can be loaded into the new cluster.
• Synchronize the database users with the server logins.
• Redirect client access to the new server.

Prevent Problems by Taking Backups

Regardless of which option you choose to upgrade your ASE server, you must take good backups before you start. Yes, take really good backups!

In case of a glitch in the upgrade process, dump and load, or any other unplanned incident, you might not have the luxury of time to work through the problem. You are forced to reverse the upgrade to the original state. In most cases, this is a backup-restore process.

Prerequisites for the Sybase In-Place Upgrade

For this example, I’m using the example of upgrading an existing non-clustered Sybase ASE 15.0.3 server to a new 2 node Sybase ASE Cluster Edition 15.5 server with the in-place upgrade methodology. For simplicity I call the 2 nodes syb1 and syb2.

I want to discuss what is possible with the in-place upgrade, how the upgrade is done, and how to mitigate any problems.

Unlike cluster server preparations from other database vendors, Sybase’s prerequisites are fairly minimal and straight forward. Sybase requires you to have all database devices for your existing server on a SAN device. They help you put your database devices on the SAN device, using the old Sybase disk mirror to bail you out, and transfer all your devices to the SAN. Sybase does this for you without any downtime or negative impact to your server.

In addition to working with SAN devices, it’s helpful to understand the concepts of: shared disk architectures and cluster topologies, failover of nodes with network architectures, and knowledge of SCSI-3 devices, with I/O Fencing.

The basic steps to implement the upgrade are:

• Create a disk mirror of every local database device to a SAN device. To prepare for ASE Cluster Edition, you should make the SAN database devices slightly larger than the local devices to accommodate some ASE Cluster Edition overhead.

Command Example:

disk  mirror
name = "logical device  name" ,
mirror = "physicalname"

Please consult the System Administration manual for additional options that apply to your environment.

• Monitor the log file to see when the mirror is 100% in sync.
• The final step is to “break” the mirror and have the ASE server run entirely on the SAN storage.

  Command Example:

  disk  unmirror
  name = "logical device name"
  , side = "primary"
  , mode =remove 

Because every node in the cluster must see the database devices the same exact way, you should use logical device links as physical device names. This added abstract layer will protect your cluster from outages if nodes try to take over and the physical device names are different. Remember: logical device links as physical device names are your friends.

Understanding Database Prerequisites

Once you have your database devices available on your SAN device, you can focus on the database prerequisites. In order to qualify for an in-place upgrade, your existing ASE server must be on one of these releases and ESD levels:

• ASE 12.5 through ASE 12.5.4 ESD #8
• ASE 15.0 through ASE 15.5

Note: If you are on an earlier version, upgrade to a supported in-place upgrade version first, and then proceed with the Sybase ASE Cluster Edition 15.5 upgrade.

Sybase ASE Cluster Edition is a 64 bit system only. If you are on a 32 bit version of ASE, you need to apply additional steps to prepare for this upgrade scenario. For a more detailed list on system prerequisites, please reference the Sybase ASE Cluster Edition System Upgrade Guide.

Install the Sybase ASE Cluster Edition Software

Shared Installation

With the new 15.5 version, you have to option to install the software either as shared installation or private installation. If you use the shared installation, you need to have access to a shared filesystem that is accessible from every node in the cluster. Although the shared installation is more convenient, it presents other risks like a single point of failure if the shared filesystem goes offline.

Private Installation

The private installation provides a dependency separation between nodes for added stability and protection. The private installation installs the Sybase software on each node, and does not require a shared filesystem. You need to maintain a strict file structure and placement discipline, because every node must access the software identically.

Pre-Upgrade Steps

Once you completed the prerequisites, you need to shift your focus to preparing the databases, and the database server.

• If you are upgrading Adaptive Server, the previously installed version of the server must be running. If you are upgrading Backup Server, Historical Server, Monitor Server, or XP Server, those servers must not be running.
• Stored procedure text in the syscomments table is required for the upgrade. If you deleted the text, you must add it back again.

Note: As a best practice: if you don’t want to display the text, hide it by using the sp_hide_text stored procedure instead of deleting it.

• Resolve reserved words using quoted identifiers. This is a simple check by installing the upgrade package and then executing sp_checkreswords.

Caution: This step is simple enough, but if omitted, can lead to serious issues during the upgrade process.  

• Perform some standard tasks that apply to any database server upgrade.
• Verify users are logged off.
• Check for database integrity. Run DBCC commands to complete this step.
• Back up the databases.  As mentioned before, this will be your lifeline in case of a failed upgrade.
• Ensure that master is the default database for the “sa” user.

• Prepare the database and devices for upgrade by following these steps:
• Disable auditing
• Disable Job Scheduler by ensuring the “enable Job Scheduler” is off.
• Archive auditing data and truncate auditing tables.
• Disable disk mirroring.

  Note: Sybase ASE Cluster Edition 15.5 does not support disk mirroring. This is important if you used the disk mirror approach to move your local database devices to the SAN. Please make sure that all device mirrors have been disabled.

• Verify that your $SYBASE environment variable points to the location of the new Adaptive Server software files you just installed.

Manual Upgrade of an Existing ASE Server

Your upgrade approach will be completely different based on the various upgrade options. I want to focus on the manual upgrade from a non-cluster ASE server to the ASE Cluster Edition 15.5.

For the full details of the manual upgrade, please review the Sybase ASE Cluster Edition Upgrade manual. The summary of the steps is:

• In order for Sybase ASE Cluster Edition to work and communicate, the unified agent must be running on each node of the cluster.

Note: Now is a good time to get into the habit of starting, and verifying the unified agent before starting any database server.

Start the Unified Agent:

$SYBASE/UAF-2_5/bin/uafstartup.sh &

• Start your existing Sybase ASE server. Change the $SYBASE and $SYBASE_ASE variables to reflect the new location of the software. This process must be repeated when a restart of the existing Sybase ASE server is required.
• Execute the $SYBASE/$SYBASE_ASE/upgrade/preupgrade command from the new software location to prepare your server for the upgrade. If there are errors reported, correct them and restart your existing Sybase ASE server. Repeat this step until no errors are displayed.
• Check your existing Sybase ASE databases for new “reserved words” by installing and executing the sp_checkreswords stored procedure. Correct any errors prior to continuing the upgrade process.

Caution: Omitting this step can lead to serious problems during the upgrade process.

• One important part of installing a Sybase ASE Cluster Edition server is the requirement to have at least 2 network connections; 3 connections are even better. The additional network connections are needed for the server to interconnect via a primary private network and an optional secondary private network. In our example, we are using 2 private interconnects. Plus the public network access.

• After shutting down the old server, you need to proceed with the cluster preparation. The first step is creation of a new cluster input file that describes your cluster environment. The first instance of the cluster must be the old server name. For this example, the filename mycluster.inp has been chosen.

In addition, you need to have the network interconnect working. This is the back bone connection between the cluster nodes.

Here is an example of the mycluster.inp file, based on a shared installation:

#all input files must begin with a comment

[cluster]
   name = mycluster
   max instances = 2
   master device = /dev/raw/raw1
   interfaces path = /sybase/
   traceflags =
   primary protocol = udp
   secondary protocol = udp

[management nodes]
   hostname = syb1
   hostname = syb2

[instance]
   id = 1
   name = syb1
   node = syb1
   primary address = syb1-ppriv
   primary port start = 38456
   secondary address = syb1-spriv
   secondary port start = 38466
   errorlog = /sybase/ASE-15_0/install/syb1.log
   interfaces path = /sybase/
   traceflags =
   additional run parameters =

[instance]
   id = 2
   name = syb2
   node = syb2
   primary address = syb2-ppriv
   primary port start = 38556
   secondary address = syb2-spriv
   secondary port start = 38566
   errorlog = /sybase/ASE-15_0/install/syb2.log
   interfaces path = /sybase/
   traceflags =
   additional run parameters =

• Create the quorum device with the input file create in step 6. This is the core of the share disk cluster.

  Start the new instance with the old master device:

  $SYBASE/$SYBASE_ASE/bin/dataserver\
  --instance=server_name\
  --cluster-input=mycluster.inp\
  --quorum-dev=/dev/raw/raw102
  --buildquorum
  -M$SYBASE

• You’re ready to run the upgrade utility. instance_name is the first instance in your cluster that has the same name as the server from which you are upgrading:

  $SYBASE/$SYBASE_ASE/upgrade/upgrade  -S instance_name –Ppassword

• Create a tempdb for each instance in the cluster.

Note: This step is important. Without having the global temporary database for the second node in place, the cluster won’t start.

1>create system temporary database tempdb1  for instance syb1 on tempdb1 = 100
2>go
1>create system temporary database tempdb2 for instance syb2 on tempdb2 =  100
2>go

tempdb1 and tempdb2 are new raw devices on the SAN, accessible by both nodes. The size of the tempdb is arbitrary.

• Restart the cluster with the quorum device in the run file:

  $SYBASE/$SYBASE_ASE/bin/dataserver
  --instance=server_name\
  --quorum-dev=/dev/raw/raw102\
  -M$SYBASE

• Finish the upgrade with running a few scripts as described in the Sybase ASE Cluster Edition installation manual.

Note: This is an abbreviated version of the entire install procedure, but it demonstrates how straight-forward the upgrade actually is. As always, please review the Sybase ASE Cluster Edition Upgrade manual for details, as the configurations may be different for your environment.

Once you upgraded your existing Sybase ASE server, you can add new nodes and convert your non-clustered ASE server into a multi node cluster with ease.

Conclusion

Upgrading your existing Sybase ASE server to Sybase ASE Cluster Edition is pretty straight forward. Especially if your ASE Server is on release 15.x. Keep in mind that with the 15.x release, a new query optimizer was introduced, and extra steps to mitigate possible performance degradation have to be exercised. Once you upgraded your ASE server, you now have access to new tools and methods to address availability and scalability challenges.

In my humble opinion, this is possibly the easiest upgrade path from a non-cluster database system to a shared disk cluster. Sybase ASE Cluster Edition brings your organization better database resources, uses less hardware, and strengthens your computer applications.

About the Author

Peter Dobler is an accomplished IT database professional who “makes a difference” by improving efficiencies and reducing costs for small and medium-sized businesses.  He founded Dobler Consulting, (www.doblerconsulting.com) a Tampa, Florida consulting firm that delivers implementation expertise for Sybase, Oracle, and MS SQL Server in 2000. His 25 plus years in technology started in Basle, Switzerland in 1985. Peter uses his extensive experience to hone his talent as a proven resource for producing streamlined IT solutions. He currently engages in strategic alliances and special projects with Sybase, the enterprise software and services company. He can be reached at: mailto:pdobler@doblerconsulting.com or 813-322-3240.
Read his Database Trends Blog (Behind the Scenes of Database Evolution) at: http://www.peterdobler.com, and his Technology Tips Blog (Step-by-Step Instructions on Today’s Challenging Technology) at http://www.techtipsntrick.com.

Other Articles of Interest:

“Sybase ASE 15.5 — The Need for Speed”, Database Journal, www.databasejournal.com, May 2010.
“Sybase ASE 15 – Semantic Partitions to the Rescue”, http://www.sybase.com/files/Feature_Articles/Sybase_ASE15_SemanticPartitions_article.pdf.

Reviews on Peter Dobler’s articles

“IMDB said to be the New Frontier of Database Architecture,” http://www.dbajobsandcareers.com, Database Blog, Review, June 1, 2010
“Performance Enhancement and the In-Memory DBMS Opportunity”, International Sybase User’s Group, http://www.isug.com/common/Index.html, March, 2010.

Back in the 90′s a group of German engineers put together the world’s first grid computing network with over 100 PCs running on the first version of the Linux operating system. It was a great success and everybody called it the dawn of a new technology that will change the computing world forever.

What these engineers didn’t understand was how database engines worked at the time and how they actually set the trends for hardware development. The database engines were calling for Massive Parallel Processing (MPP) systems that offered dozens of CPUs in one single server platform. Just when we thought the mainframe was dead – with grid computing, we witnessed the birth of the open systems mainframe.
To offset these MPP systems, software architects created a middleware layer to get away from these monsters. Now we have these MPP systems in the center of the universe and all these middleware servers dancing around them.

For years to come, companies filled their data centers with hundreds of middleware servers and dozens of MPP systems. Cooling and power supplies were running at their peak and data center managers didn’t know how to support this hardware excess into the future.

This became the birthplace of server virtualization. Within a few years, server virtualization became the main focus for every company searching for infrastructure savings. Consolidating middleware servers was an easy task and a huge success story shared with pride by the project managers.

But one area was not so successful in consolidating hardware. MPP systems didn’t go away quietly. It turned out that the database systems were too much to handle for the server virtualization frenzy. Yes, countless efforts have been undertaken to move the databases off these monsters, but the virtual world couldn’t provide the performance needed to support the databases.

Remember our grid computing story? The vision of sharing an army of small computers to produce the same computing power as the massive MPP systems seemed lost forever. Until the ugly truth about MPP systems became obvious. Running huge MPP systems are not only energy intensive, but the associated maintenance costs are also burdensome. Buying a replacement MPP system was the only option. However, spending money got increasingly tight over the past several years. This all became a Catch-22.  You needed to spend more to increase your costs!

Database vendors to the rescue: grid database technology seems to be the way out of under the massive weight of these MPP systems. Take a couple of low-cost powerful dual or quad core servers and spread the workload over multiple servers. Not only do you get instant high availability, but you gain added scalability beyond your MPP platform’s physical limitations. There are two major methodologies in achieving grid databases; shared everything and shared nothing.

The shared everything category is dominated by Oracle and Sybase. Both systems are able to instantly failover database processes should one participating server go down, aka. high availability. And both can dynamically scale their CPU power by adding more servers to the grid, and both systems can balance the workload among all participating servers. Oracle RAC and Sybase ASE-Cluster Edition are the most sophisticated systems available today. If you want to squeeze the maximum out of your existing hardware or if you are seeking to replace energy-wasting and maintenance-fee-eating MPP monsters, these two databases are the weapons of choice.

The second methodology is shared nothing. Microsoft SQL Server 2008 Federation Data Store represents the leader in this category. Unlike the shared everything technology, the shared nothing approach has a clear distinction between local and global data. The data federation approach allows combining data stored locally on multiple individual databases. It acts as an aggregator of multiple databases. This is not as sophisticated as the shared everything approach, but it gets the job done as well.

There’s a third contender, Sybase IQ Multiplex. This system uses a hybrid approach, shared data, but no shared cache. This is very unique and no other database vendor has anything like it. Sybase IQ is Sybase’s data warehouse engine. A column-vector database that set new performance benchmark records by having just one distinctive writer node in the cluster and a nearly unlimited number of reader nodes.  But there’s a caution: Never try to run an OLTP application on this system. This system is built for data warehousing and massive analytical reporting, a perfect match for data hungry BI tools.

There are a couple of other database vendors that are offering grid database technology of some flavor. This article is not meant to create a competitive analysis between all of these systems, but a starting point to get your imagination going. The bottom-line is that preserving energy becomes more and more important and software vendors are providing solutions to maximize low-cost and low-energy consuming hardware. The future belongs to grid databases.