Skip to Content

A Deeper Look At Sybase,  I’m planning to do a series of blog posts on the various Sybase data  management products — to make the point that Sybase is not just about  mobile stuff (as the casual observer might be led to believe).

Today, it’s about Sybase Adaptive Server Enterprise, or ‘ASE’ as it’s usually called.
ASE  is Sybase’s flagship database. It is a versatile, enterprise-class  RDBMS which is especially good at handling OLTP workloads. ASE is used  intensively in the financial world (capital markets, stock exchanges,  banking, insurance), in E-commerce, as well as in virtually every other  area.

So how did we get here?

ASE started its life in the  mid-1980’s as ‘Sybase SQL Server’, originally developed from Bob  Epstein’s home in Berkeley, California (Bob and Sybase’s other founder,  Mark Hoffman have long left Sybase). In those early days, relational  databases were mostly found in academic environments: relational  technology was just not mature enough for the requirements of business  systems, and operational systems at the time were typically using IMS (a  hierarchical DB), IDMS (Codasyl/network DB), or were using ISAM files  or some custom home-grown type of file management.

When it  appeared on the market, Sybase SQL Server was innovative in a number of  ways. Perhaps the most important aspect was that ASE was architected for  client-server from the ground up. The original designers had correctly  envisioned that networks would become pervasive (an enabler and  necessary requirement for client-server architectures). In contrast,  other DBMSs have long been monolithic programs where a each user would  essentially start up a full copy of the database; for example, Oracle  only ‘bolted on’ client-server functionality in the mid-90’s. Sybase’s  client-server architecture made it very resource-efficient: I recall  that the amount of memory required by Sybase for each additional user  connection was only ~45 KB in 1990 – a big difference with those  monolithic databases that required megabytes of memory for each  additional user.

In the early 1990’s, a number of trends  coincided that allowed Sybase to take Wall Street by storm. Perhaps the  most important factor was the advent of fast and relatively cheap  Unix-based servers (remember Pyramid? remember ‘Sun Microsystems’ whose  ‘SunOS’ became a Unix standard for years to come?).
Up till then,  business applications were typically running on mainframe-type hardware  (anyone remembers Amdahl and Fujitsu besides IBM?). Though Unix servers  could not achieve the availability and reliability levels offered by  mainframes, their performance, cost advantage and ease of use made them  attractive. As it happened, Sybase SQL Server ran extremely well on  those Unix boxes, and as a result Sybase benefited greatly from the  drive to replace mainframes.

Another factor at the time was the  transformation of batch-driven processing to online systems. A banking  system in the old days would update its accounts once per day,  processing a batch of mutations against a database of accounts; the  mutations would come in on magnetic tapes, sorted by account number, and  were processed in batch. The business need for more real-time updates  was driving a conversion to online transaction processing (OLTP), where  the result of an individual mutation could be seen immediately rather  than only at the end of a long batch job (I know this sounds trivial  today, it just show how much technology has evolved).
(just to put  things in perspective: the word ‘analytics’ didn’t even exist in those  days — ‘reporting’, ‘decision support’ or ‘management information  system’ would probably have been the terminology describing data  aggregation — which typically was a big pile of paper printout,  delivered to your desk once per week/month/quarter).

Sybase SQL  Server was designed for OLTP workload. OLTP is characterized by small,  short and relatively simple transactions. The classic example is a bank  transfer, which is in essence a database transaction consisting of two  updates (i.e. adding EUR 100 from one bank account and subtracting it  from another account). OLTP workloads tend to have massive amounts of  such transactions, and Sybase SQL Server handled such workloads  exceptionally well.
My own first encounter with Sybase was in 1989  for an ambitious real-time logistics system. Sybase SQL Server provided  innovations such as stored procedures, triggers and a cost-based query  optimizer.
These are taken for granted today, but they were novel and exciting features at the time.
All  together, Sybase created the first commercially successful  client-server RDBMS capable of handling real-world workloads through a  SQL interface. The Sybase flavour of SQL was -and still is- called  ‘Transact-SQL’.

It was not a coincidence to for Sybase to gain a  foothold at Wall St: those firms are always looking for new technology  that allows them to gain a competitive edge. Sybase SQL server provided  just that.
As a result of the big success of Sybase in the early  1990’s, many critical systems in the financial sector are still running  on Sybase today. These are often complex and critical systems related to  securities trading on which a huge amount of specialized development  and tuning effort has been spent. Since Sybase has proven to be  efficient, robust and reliable for so many years, many customers have  stayed with Sybase. As just one example, most of the trading systems  making up the world market for derivatives (a class of complex financial  products) still run on Sybase-powered systems today.

Now, about  that name ‘SQL Server’… chances are you’ve heard that name before,  but prepended with ‘Microsoft’. Unlike what many Microsoft users think,  SQL Server is not originally a Microsoft product.
During the early  years of Sybase, Microsoft was a Sybase distributor, essentially  reselling the Sybase product for OS/2 and (later) Windows NT under the  name ‘Microsoft SQL Server’; all engineering was however done by Sybase. 
Around 1994, Microsoft basically bought a copy of the source code  of Sybase SQL Server for the Windows platform and then went its own way.  As competitors, Sybase and Microsoft have been developing their  products independently ever since. Microsoft has mostly emphasised  ease-of-use and ‘Window-ising’ the product, while Sybase has focused on  enterprise features, maximising performance and reliability, and  catering to the high end of the OLTP market.
When releasing version  11.5 in 1997, Sybase renamed its SQL Server product to Adaptive Server  Enterprise (ASE) to better distinguish itself from Microsoft SQL Server  and to emphasise its focus on enterprise systems.
Because of the  common background, there are still many similarities in today’s versions  of ASE and MS SQL Server. For example, both have the concept of  ‘master’, ‘model’ and ‘tempdb’ databases in a server, and of system  stored procedures starting with ‘sp_’ (like sp_who, sp_helpdb).
Also,  both ASE and MS SQL Server have an SQL implementation called  ‘Transact-SQL’, which are still quite similar though they have diverged  more and more over the years. Still, probably no two databases are as  similar as Sybase ASE and MS SQL Server, so it is relatively simple to  learn one if you already know the other.

So, Sybase earned itself  a reputation for producing a reliable, high-performance database that  became the workhorse of mission-critical financial systems. 
Over the course of the years, naturally also a few things happened that were somewhat less successful.
One  ‘issue’ worth mentioning here at the SAP blog site is what happened  somewhere in the first half of the 1990’s. A German software company  that was yet little-known in the USA, approached Sybase because they  wanted to run their application on Sybase SQL Server — the most popular  financial database, after all.  However, their application was designed  such that it caused too many concurrency problems (locking) in Sybase  SQL Server. The Germans therefore requested Sybase to implement  row-level locking to solve this problem (at that point, Sybase only  supported page-level and table-level locking). Accounts differ on the  reasons why, but Sybase declined the request. What happened next is  history: SAP (you guessed it, right?) ended up running on all major  databases except Sybase, and consequently Sybase missed out on the big  wave of ERP-driven business in the rest of the 1990’s (Sybase did  eventually implement row-level locking in version 11.9, offering a choice of three  different lock schemes).
Now that SAP has acquired Sybase, and  Business Suite will be running on Sybase ASE later this year, history  has more or less come full circle. I’m confident that ASE will be a  great platform for SAP ERP, albeit indeed a bit late.

For the  first few years, SQL Server was Sybase’s only product. For many years,  it remained the #1 product in Sybase’s product line. By its installed  base and prominent role in mission-critical systems, it still is  Sybase’s flagship database today.

Next: A Deeper Look At Sybase: ASE Today.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

    1. Markus Doehr
      …and at that time you could run a Sybase database client again a Microsoft SQL Server 6.5 🙂 Version 7.0 had some issues with that setup but technically it worked. 🙂

      (0) 
      1. Rob Verschoor Post author
        In MS SQL Server 7.0, Microsoft made a small change to the TDS protocol (used for the client-server communication), with the result that Sybase-TDS clients could no longer connect to Microsoft-TDS servers (and vice versa, I believe).
        (0) 
  1. Lars Breddemann
    … code base split
    … takeover by SAP

    That’s pretty much what was done with Adabas D -> SAP DB -> MaxDB -> SAP MaxDB ten years ago.

    And still there are many traces in the current versions of both MaxDB and Adadabas D that proove the shared heritage (control, x_cons, …)

    Singlerow-locking capability is still important nowadays, lock escalations still not really what any developer likes to see.

    I’m really curious to see how another DBMS in the pool changes the landscape.
    So, keep on blogging!

    regards,
    Lars

    (0) 
  2. syb anva
    Hi Rob,
    Thanks for posting the History of ASE!
    Its really nice to know the historical background of our ASE database.
    (0) 

Leave a Reply