Let’s set the record straight. Our competitors have propagated some MYTHS about SAP Sybase ASE… it’s expensive, it trails behind other databases in terms of performance, it’s difficult to manage, it’s not disaster recovery-proof, and on and on. So herein are the FACTS about SAP Sybase ASE costs, performance, efficiency, security, reliability, availability, and application suitability. Read on and you’ll see why 90% of the global banks and securities firm trust SAP Sybase ASE to run their business, and how Indian Railways serves 20 million customers daily using a distributed SAP Sybase ASE system. Let the myth-busting commence.

According to an IDC report SAP Sybase ASE costs 28% less than other leading RDBMs. Lower costs are achieved through efficient use of storage, processor, and staff resources. IDC estimated a cost savings over five years of $340,000 per 100 users over other databases because SAP Sybase ASE requires significantly fewer IT staff resources and fewer hours of training.

A Bloor Research study found 22% fewer security patches than Oracle suggesting that SAP Sybase ASE is less vulnerable to security threats. Bloor also found SAP Sybase ASE needs 22% less time to apply security patches and 21% less time to resolve support issues than Oracle. This equates to higher uptime and more availability of the data.

SAP Sybase ASE delivers superior performance for extreme transaction process environments – both for SAP Business Suite applications and for custom-built applications. SAP Sybase ASE recently recorded leading two-, four- and eight-processor two-tier SD standard application benchmark results for x86-based Linux systems – delivering near-linear scalability from 2 to 4 to 8 processor systems.

Any investment in SAP Sybase ASE for SAP Business Suite is protected – 100% of customer investments in SAP Sybase ASE will be credited towards the SAP HANA license acquisition costs. And as key components of the SAP Real-Time Data Platform, SAP Sybase ASE and SAP HANA interoperate together. All of this makes for excellent investment protection.

To read the entire Fact Sheet “The Truth about Databases: Getting to the FACTS on SAP Sybase ASE” visit: https://scn.sap.com/docs/DOC-43289

Error 4224

Severity

10

Message text

WARNING: The transaction log for database '%.*s' (dbid %d) can no longer be dumped due to user '%.*s' (suid %d) executing %s.

Explanation

This warning is raised when a user executes a command that is minimally logged (such as select into) or otherwise does something that interrupts the sequence of transactions in the log (such as dump transaction with truncate_only).  After this happens, attempts to dump the transaction log will fail until a full database dump is taken.  

Action

If you wish to continue taking transaction log dumps you will need to take a full database dump first.

Database options can be set to prevent the use of commands that break the transaction log dump sequence.  See the Reference Manual entry on sp_dboption for details on the "select into", "full logging" and "enforce dump tran sequence" options.  Turning "select into" off prevents the use of most minimally logged commands but does not prevent the use of dump transaction with truncate_only.

If you don't care about taking transaction log dumps, consider setting the "truncate log on ckpt" option for this database.

Versions in which this error is raised

This warning was introduced in ASE 15.5 ESD #4 and 15.7 ESD #1 to help identify who and what was causing transaction log sequences to be interrupted.  Until 15.7 ESD #2, this warning was also unnecessarily raised for databases that had the "truncate log on ckpt" option turned on.

--

One of my current projects is updating and expanding the ASE Troubleshooting and Error Messages Guide (TSG).  As I update existing error writeups and create new ones, I'll be posting the new content to this blog rather than making you wait for the next edition of the TSG.  If there is an error message that you are particularly interested in seeing a writeup on, please feel free to send me a direct message giving the error number or text and any comments you may have on the message and I'll plan to work on it sooner rather than later.  If your need for an explanation is urgent, please follow the usual process for opening a Technical Support case (SAP message) for assistance with your situation.

-bret

One of my current projects is updating and expanding the ASE Troubleshooting and Error Messages Guide (TSG).  As I update existing error writeups and create new ones, I'll be posting the new content to this blog rather than making you wait for the next edition of the TSG.  If there is an error message that you are particularly interested in seeing a writeup on, please feel free to send me a direct message giving the error number or text and any comments you may have on the message and I'll plan to work on it sooner rather than later.  If your need for an explanation is urgent, please follow the usual process for opening a Technical Support case (SAP message) for assistance with your situation.

The following is an updated writeup for error 225 that adds information about inconsistent use of qualified object names causing the error in some (but not most) circumstances.

-bret

Error 225

Severity

11

Message text

Cannot run query--referenced object (name  %.*s) dropped during query optimization.

Explanation

This error occurs when Adaptive Server fails to build an execution plan for a stored procedure or an ad-hoc query because a referenced object was not found.

Known causes of this error include:

• The value of the number of open objects configuration parameter is too low
• Using a mix of qualified (database.owner.name or owner.name) and unqualified (name) object references.

There may be other causes.  This is not a serious error and does not indicate corruption. However, it may prevent you from running some stored procedures and ad-hoc queries.

Action

Using sp_monitorconfig "number of open objects", check if the max_used value equals the current configuration value from sp_configure "number of open
objects"; if so increase the value if feasible. For information about memory-related configuration parameters, refer to:

• The chapter “Setting Configuration Parameters” in the System Administration Guide: Volume 1
• Adaptive Server Enterprise Performance and Tuning Guides

Check the code being executed for inconsistent use of qualified and unqualified object names and rewrite using consistently qualified names

Example

This code uses a mix of tempdb..t, dbo.t, and t to reference the same table:

       use tempdb

       go

create proc p as

  create table dbo.t(c1 int)

  insert t  select dbid from master..sysusages

  select * from tempdb..t where c1=1

go

The code can be rewritten using consistent naming as:

create proc p as

           create table dbo.t(c1 int)

  insert dbo.t  select dbid from master..sysusages

  select * from dbo.t where c1=1

   go

If neither action resolves the 225 errors, call SAP Product Support (Sybase Technical Support) for assistance.

Versions in which this error is raised

All versions

SAP announced today that the latest release of SAP Sybase ASE (SP100) delivers faster processing of unstructured data, a new methodology to minimize storage space and advanced tools to increase data availability — all critical characteristics for meeting the challenges of extreme online transaction processing.

In addition, recent benchmark results indicate near linear scalability: SAP Sybase ASE 15.7 recorded leading two-, four- and eight-processor two-tier SD standard application benchmark results for x86-based Linux systems just one more testament to the exceptional performance SAP Sybase ASE achieves.

The latest release of the SAP Sybase ASE developer edition or express edition can be downloaded from the SAP Sybase ASE Developer Center

Read the press release here.

It has been quite a long time since I have been able to write anything in this public space.   The reason is that I have been completely absorbed by one of the most exciting projects I have been managing for the last couple of years:   moving the largest ASE site in the country I live from ASE 12.5.4 to 15.7.

I must confess, I am quite thrilled with 15.7.  Not only because it is brand new (it is like sitting in a new  car - you smell the flavor of the new parts and hear the new dialect of your engine).  But also because with ASE 15.7 you must be as adept as the speed-car driver.  You must learn the curves on the road ahead.  You must know how to steer.  You must prepare well for the ride.   And  you must be quick to react.  After all, driving at 80 mph and 160 mph requires different skills.

A comparison to 12.5.4 comes to mind.  12.5.4 has been for years a work-horse.  It run well.  A bit heavy at turns.   But as  DBA you might have known that, however badly you do your job, it will still run.  You may drive it into a wall, to be sure.  But you must be really creative to do it fast.

With 15.7 things are different.  It is a beautiful creature.  It may show you performance you might have only dreamed before.  But you better know what you are doing.  If you don't know how to steer, better don't turn on the engine.

I will not go into details at this time.  I will be posting things more technical at later stage (when I will free myself up more for the task).  For now, I will only throw a few notes on what I have seen.

Performance:

I have seen performance leap from 1000 TPS to 6000 TPS for the same application - running on the slower ASE host.  Very basic ASE tuning.  Make sure you know your host well.  ASE 15.7 runs better when it runs on the right host.

I have seen a leap from 2000 SP/Sec to 5000 SP/sec for the same application.  ASE 15.7 has introduced new patented features to manage plan/object sharing.  It is more light-weight as a result and runs much faster.

Monitoring:

I have seen customers getting frightened by the changes in SYSMON report.  You may see 99% utilization where you have been used to see 10% or less.  Read the documentation first, get scared (if needed) only after.  ASE 15.7 is a difference creature (I refer to the threaded kernel, which is the only one you should use).  It's heart beats differently.   You must learn to listen before you judge.

There is a fantastic degree of transparency with 15.7.   There are areas in ASE 12.5.4 that you might only guess what happens inside.  In 15.7 you may actually look into the guts of your server and see what it is doing.  There are still things you don't know.  But there is a lot of information you may find digging in that was not available before.

Satisfaction:

This on is problematic.  How do you measure it?  Oh, yes - end-user experience.  There are DB migration projects in which you switch the engine and start hearing complaints of the end-users:  why is it so slow?!  why my application get stuck all the time?!  I have been a little bit surprised with the 15.7 migration I have been orchestrating this time.  Despite all that I have seen from the inside, the end-users were consistently reporting overall satisfaction with the way their applications perform.   It is definitely an end-result of the preparations done (and there was a lot of work done in preparation for this migration).   But not only.   In my opinion, with ASE 15.7 we at last have yet another ASE work-horse version.  Give it the right attention.  Give it the right resources.  Heed to its needs.  It will give you unprecedented performance.

Hey cheetah, nice to meet you.

ASE 15.7?

From now on it is a history...

ATM.

Last night I helped a friend at a small company install, configure and tune Sybase SQL Server 11.0.3.3 for Linux using the same method as I used on HOWTO: INSTALLING AND RUNNING SAP / SYBASE SQL SERVER 11.0.3.3 ESD 6 ON UBUNTU LINUX USING KVM. No, I didn't provide the software, they already had it.

There is something refreshing going to sybinit using ctrl-a to go to the next screen.  No X-Windows needed.  No Java.  Just a simple DBMS doing DBMS work.

A new whitepaper was published describing the new "online" utilities such as "reorg rebuild" and "create index".

You can find this here: http://scn.sap.com/docs/DOC-44384

Hello database experts,

more and more people are interested in Sybase ASE as new database solution for their SAP systems in cause of unknown future of MaxDB and the high prices of databases and features of RDBMS like Oracle and DB2.

But how performant is Sybase ASE?

How big is the migration effort?

How good is the compression?

How big is the administration effort?

I will clarify some aspects and bring a little bit light into the darkness or more or less bad documented areas.

Migration

Prerequisites

• Sybase section on note888210 - NW 7.**: System copy (supplementary note)
• Implement note collection for SYB 7.x (1612437 - SYB: System copy with SMIGR and table partitioning)
• BW Report to determine the number of partitions in BW system (Report RS_BW_PRE_MIGRATION;  1690674 - RS_BW_PRE_MIGRATION)
• SMIGR_CREATE_DDL notes/fixes (search for them, most once should be included in the collection note; parallel index creation option)
• replace migration tools (R3load min. pl 402, R3ldctrl, R3ta, R3szchck, DBSL min pl431, ODBC min. 15.7.0.508)
• Migration Best Practice (1680803 - SYB: Migration to SAP Sybase ASE - Best Practice)
• Update SYB SP110 ( 1590719 - SYB: Updates for SAP Adaptive Server Enterprise (SAP ASE) )
• Unicode System or Unicode Migration (SYB ASE runs only with UC systems!)
• Konfiguration of the Sybase database (1749935 - SYB: Configuration Guide for SAP ASE 15.7 )http://service.sap.com/sap/support/notes/1749935

Test scenario:

Source System NW731 SPS10 (distributed)

MaxDB 7.9

Windows 2012

Physical Size 2TB

Logical Size 1.7TB

40GB RAM

Target System NW731 SPS10 (distributed)

Sybase ASE SP110

Windows 2012

40GB RAM

Export/Import

1. At first all notes and new kernel/migration tools have to be updated on the source system to run a clean export
2. Second step is to run the SMIGR_CREATE_DDL to create the needed SQL files for the BW tables
3. check dictionary and other steps described in the system copy guide
4. Run the export with migration optimized settings (depends on each source database type)
5. Create the target DB (setup parameters, configuration of CPU, caches, pools and update to SP110 => Best Practice note 1680803 )
6. Start the import manually! That is important to control and setup the config and may be seperated index creation with own parameter setup
7. standard postprocessing described in the system copy guide

Issues during Sybase migration

1. R3load issue trunc log issue

[ASE Error SQL1105]Can't allocate space for object 'syslogs' in database '<SID>' because 'logsegment' segment is full/has no free extents.

Solution

It is mandatory to use at least the following component versions to run a migration:

- ODBC 15.7.0.508

- DBSL 720_EXT UC 64, pl 431

- R3load 720_EXT UC 64, pl 402

Note: log segment must be big enough to handle the I/O that the checkpoint can be triggered in this time

=> increase size of the log segment or decrease parallel degree (=import jobs)

2. Partitioning issue

number of partitions > 8000 partitions, no official statement how many partitions are supported! My tests results show a working number of 1500 partitions.

Report RS_BW_PRE_MIGRATION: A buggy display of size => that are only 6GB not 6TB!

So we have 2 options because if I import this table with 8172 partitions, because I get an error while import the data:

(SYB_IMP) ERROR: DbSlPrepare/BegModify   
failedrc = 99, table "/BIC/FZSDM1CS3"
SQL error 30046)
errormessagereturnedbyDbSl:
[ASE Error SQL21][SAP][ASE ODBC Driver][Adaptive Server Enterprise]WARNING - Fatal Error 702 occurred

Solution

Option 1

Collapse the cube to at least 1500 requests (=> 1 REQ = 1 Partition)

Option 2

Create an entry on the source system in table rsadmin (1691300 - SYB: Unpartitioned F fact tables for InfoCubes) with :

Note:

=> Table must be exported again with new run of SMIGR_CREATE_DDL, because the new table creation statement without partitioning must be written to the sql files.

=> so please analyze this before you start the export! Collapse or export with rsadmin option!

3. Index creation issue (sorted creation)

Index creation fails with:

SQL error 1530: Create index with sorted_data was aborted because of a row out of order.

If index creation fails due to data being out of order, the DDL template file mapping is wrong for the respective package.

Solution

Map the failing package to DDLSYB_LRG.TPL to omit the sorted_data option for the creation of the SAP primary keys. If the R3load task files have already been generated, modify the corresponding command file (<package name>__DT.cmd).

Sybase documentation to this option:

The sorted_data option can reduce the time needed to create an index by skipping the sort step and by eliminating the need to copy the data rows to new pages in certain cases. The speed increase becomes significant on large tables and increases to several times faster in tables larger than 1GB.

If sorted_data is specified, but data is not in sorted order, Adaptive Server displays an error message, and the command fails.

Creating a nonunique, nonclustered index succeeds, unless there are rows with duplicate keys. If there are rows with duplicate keys, Adaptive Server displays an error message, and the command fails.

Tips for migration

Increase migration performance with seperated data import and index creation, with different DB settings. All settings therefore are described in the Best Practice migration guide.

Summary

Compression

Compression ratio like MSSQL (no wonder because MSSQL based on Sybase source code) but not as good as e.g. Oracle 11g compression for OLTP, but this is only my impression, because I have no 1:1 example on Oracle.

In Oracle we have normally a block size of 8k and there the block compression takes place. A index compression and a secure file (LOB files) compression.

With Sybase we have a row compression to compress away empty spaces/zeroes in fixed length columns.

Both page dictionary and page index compression strategies are used at the page/block level and last but not least the LOB compression for large objects.

This all happens with a SAP standard block/page size of 16k.

Compared to MaxDB this is a quantum jump not only the fact that you save disk space, you also increase the efficiency of your data cache.

Performance

Here are a bit more tests required to take a significant statement. SAP tests results in a performance boost of 35-40% compared to MaxDB.

Migration effort

Not more effort compared to another DB. You just have to read the migration Best Practice of SAP and notice the mentioned known errors.

It is definitively in cause of the compression and partitioning features a lot of faster than MaxDB and a good alternative for all other more expensive DBs. It fits into the concept of SAP for the next years.

Not all functions and features are as good documented/integrated as wished for the customers but SAP keeps going on to improve this things.

Administration effort

The integration of the tools in dbacockpit are pretty good, but such a nice colorful and gladly clickable interface like the database studio is not integrated in Sybase ASE. The people who already familiar with the commandline based administration like Oracle or DB2 are learning fast the new commands/stored procedures. The procedures are nearly the same like MSSQL - no surprise or?

A automated configuration check or script for the whole configuration would be really helpful. I have written my own scripts because I don't want waste time to copy paste over 100 parameters for each DB which I'm going to install.

It is also easy to update the Sybase ASE with a GUI wizzard, but to set all the additionally parameter for performance which are not described in the configuration note, you will need some time to size the perfect values.

I hope I could show you some new interesting facts of Sybase ASE. It is a definitively a good alternative to MaxDB and must now accept the challenge against Oracle, DB2, MSSQL etc. SAP has still some work to do to fully integrate all functions.

If you have any further questions, don't hestate to comment the blog or contact me or one of my colleagues at Q-Partners ( info_at_qpcm_dot_de )

Best Regards,

Jens Gleichmann

Technology Consultant at Q-Partners (www.qpcm.eu)

SAP ASE 16 provides scalability and speed to support higher throughput and lower latency; security to ensure data privacy and system auditability; and, simplicity of database operations to maximize operational efficiency and lower costs.

Scalability, speed, security, simplicity…these were the guiding principles for our engineers. We’ve increased scalability and speed with extensive optimization in its transaction concurrency management, query plan execution, data compression and utilization of computing resources in large SMP servers. Security enforcement and system auditability have been augmented to provide customers more flexibility to adapt to their specific regulatory compliance needs. And SAP Control Center delivers simplified database management helping to reduce overall cost of ownership.

We invite you to read the SAP ASE 16 Overview white paper to learn more about the many new features that enable you to power a new class of extreme transactional applications.

And don’t forget, we’ll be at the ISUG-Tech Conference in Atlanta April 14-17^th to give you a firsthand look at the new features in SAP ASE 16. I hope you will join us.

Next week is a landmark week for SAP Adaptive Server Enterprise, we will be announcing the launch of SAP ASE 16, our foundational release for eXtreme OLTP innovations. SAP, has also been hard at work with it’s partners to drive key innovations in the database market which we are preparing to announce next week.

SAP is a key sponsor at two industry events next week, the SAP Independent User Group (http://my.isug.com/p/cm/ld?fid=902) and the Red Hat Summit (http://www.redhat.com/summit ) where we are gold Sponsors. At both of these events we will be launching SAP ASE 16 and our innovations that we have been driving with our partners.

In SAP’s session at the Red Hat Summit on Simplified IT & real-time business management with SAP, I will be discussing our overall Data Management Portfolio Strategy, the SAP ASE 16 Launch, partner innovations, what we are doing for developers / Open Source and of course SAP HANA.

We will also have a significant presence at the Red Hat event as gold sponsors. Come by our booth, in the partner pavilion to see our innovations and ASE 16 in action. In attendance will be database and SAP experts who are ready to answer any question you have on SAP, whether it is about our Strategy or a technical or something technical you would like to know.

Look forward to seeing you at the Red Hat Summit and come and join our session.

Today, Fujitsu announced the GA of an appliance for SAP ASE, our XOLTP database engine and will initially be offered in 3 sizes, built together with SAP's Partners, Fujitsu, Violin, LSI.

The appliance is based on BYOL for SAP ASE licenses, and shipped with a per-configured SAP ASE with a 90 day trial license. Below is a summary of the 3 sizes that Fujitsu are shipping.

For more details of the appliance please and release information, please refer to the following press release and documentation :- http://www.fujitsu.com/fts/about/resources/news/press-releases/2014/CEMEAI-140415-Fujitsu-Power-Appliance-for-SAP-Adaptive.html

Looking for the techncial details on SAP ASE 16? Join the 5-part webcast series to learn about the new innovations in this latest release. Our experts will guide you through the new features and functions, demonstrate linear scalability capabilities, and show you how to simplify management of the database.  Register here for the series.

Part 1: Overview of SAP ASE 16 and Future Directions

Tuesday, April 22, 2014 10:00 AM PT/1:00 PM ET

Part 2: Achieving Linear Performance Scalability in Large Multi-core Systems with SAP ASE 16

Tuesday, May 13, 2014 10:00 AM PT/1:00 PM ET

Part 3: Extreme Transaction Processing: Ensuring Competitiveness & Agility in a World of Constant Motion

Tuesday, May 27, 2014 11:00 AM PT/2:00 PM ET

Part 4: Simplifying Development and Management in SAP ASE 16

Tuesday, June 10, 2014 10:00 AM PT/1:00 PM ET

Part 5: Enabling True “Zero Data Loss” with SAP ASE 16 and Replication Server

Tuesday, June 24, 2014 10:00 AM PT/1:00 PM ET

Register for the series or selected sessions. 

At last I have been able to start working on yet another exiting project - SAP ASE IMDB for custom application, with ~1 TB DB as an IMDB template...

I agree, working with IMDB is pretty much fun - most of the operations are cut in time drastically.  E.g., for the DBA-driven system activities, you may expect reducing the time spent on your operation to 1/6-th.  Cool. 

A note to the engineers, though.  On start up, IMDB reads the template DB from the disk before releasing the DB to general use and as it looks, it does it - single  threaded.  Since IMDB is always built from scratch, one must have though about the start-up time with a more critical eye, I think.  It takes about half an hour to recreate IMDB DB of ~1 TB from its DRDB template - which sound reasonable time to wait for the in-memory replica to become available.  But imagine that the start up has been done reading the DRDB DB devices in parallel (DB is not accessible anyway to the DB users until the IMDB DB for which DRDB is the template is brought online).  One might have cut the start up time drastically - 5-15 minutes?. 

Anyone from the SAP ASE engineering team here can pick up the challenge and speed up the start up process?   Seems like something not so hard to implement... 

Guys, I love your product.  It beats all the competitors so far.  But since you at SAP love to be challenged and make the product shine even more - here is an FR for you...

If you need client-side cooperation, be my guest...

ATM.

If you find your ASE server unexpectedly not running, the errorlog can provide some useful clues as to how it shutdown.

Obligatory anecdote:

Many years ago, I once worked a support case with a customer who had ended up with hard corruption in their database.  Their errorlog showed that ASE had repeatedly rebooted, roughly 20 times over the course of the previous night.  Their host was setup to automatically boot ASE when the OS started up.  Each time there was no indication of why ASE had shutdown.  I expressed the opinion that the lack of shutdown messages made me think the most likely cause was power being repeatedly shut off. A check of the OS logs confirmed that the host had also been rebooted many times with no indication of a polite shutdown.  The problem was soon tracked down to new cleaning staff turning the power on and off in the computer lab.  We didn't investigate the corruption further, the assumption being that a hard drive abruptly losing power while writing was a reasonable cause (and the corrupt data was clearly gibberish that didn't resemble formatted data).

Behavior for TSQL "shutdown" command (commonly called a 'polite shutdown'):

00:0006:00000:00012:2013/07/22 09:33:58.10 server  Shutdown started by user 'sa'. SQL text: shutdown
00:0006:00000:00012:2013/07/22 09:34:00.10 server  ASE shutdown by request.
00:0006:00000:00012:2013/07/22 09:34:00.10 kernel  ueshutdown: exiting
00:0000:00000:00000:2013/07/22 09:34:00.10 kernel  Main thread performing final shutdown.
00:0000:00000:00000:2013/07/22 09:34:00.19 kernel  Blocking call queue shutdown.
00:0000:00000:00000:2013/07/22 09:34:00.20 kernel  SySAM: Checked in license for 1 ASE_CORE

Behavior for TSQL "shutdown with nowait" command (commonly called an 'abrupt shutdown'):

00:0002:00000:00014:2013/07/22 09:30:11.14 server  Shutdown started by user 'sa'. SQL text: shutdown with nowait
00:0002:00000:00014:2013/07/22 09:30:11.14 server  Shutdown with nowait detected - ASE process level execution bindings will be cleared on startup.
00:0002:00000:00014:2013/07/22 09:30:11.16 server  ASE shutdown by request.
00:0002:00000:00014:2013/07/22 09:30:11.17 kernel  ueshutdown: exiting
00:0000:00000:00000:2013/07/22 09:30:11.18 kernel  Main thread performing final shutdown.
00:0000:00000:00000:2013/07/22 09:30:11.28 kernel  Blocking call queue shutdown.
00:0000:00000:00000:2013/07/22 09:30:11.80 kernel  SySAM: Checked in license for 1 ASE_CORE

Behavior for OS "kill <pid>" command:

00:0006:00000:00000:2013/07/22 09:36:07.02 kernel  ueshutdown: exiting
00:0000:00000:00000:2013/07/22 09:36:07.02 kernel  Main thread performing final shutdown.
00:0000:00000:00000:2013/07/22 09:36:07.23 kernel  Blocking call queue shutdown.
00:0000:00000:00000:2013/07/22 09:36:07.23 kernel  SySAM: Checked in license for 1 ASE_CORE

Behavior for spid-fatal error while holding a spinlock:

00:0014:00000:02998:2014/01/20 03:10:23.62 kernel Spinlocks held by kpid <kpid#>
[...fatal error, typically with a stack trace...]
00:0014:00000:02998:2014/01/20 03:10:23.62 kernel Spinlock Resource-><spinlock name> at address <address> owned by <kpid#>
00:0014:00000:02998:2014/01/20 03:10:23.62 kernel End of spinlock display.
[... typically another stack trace ...]
00:0014:00000:02998:2014/01/20 03:10:23.62 kernel end of stack trace, spid <spid>, kpid <kpid>, suid <suid>
00:0014:00000:02998:2014/01/20 03:10:23.62 kernel ueshutdown: exiting
[On a server running in threaded mode rather than process mode, the following additional line is also output:]
00:0000:00000:00000:2014/01/20 03:10:23.62 kernel Main thread performing final shutdown.

Behavior for an OS Panic:

00:0006:00000:00000:2013/07/22 09:36:07.02 kernel Engine 0 (os pid <pid> has died, server is performing emergency shutdown
[...]
stacktrace containing the function keipanic+0x8c (offset may vary by platform)
[...]
00:0006:00000:00000:2013/07/22 09:36:07.02 kernel ueshutdown: exiting
00:0006:00000:00000:2013/07/22 09:36:07.02kernel end of stack trace, kernel
service process: kpid 1114129

Behavior for OS "kill -9 <pid>" command:

[no output added to log].

Behavior for UNIX OS shutdown and reboot:

[no output added to log]

Behavior for abrupt power shutoff:

[no output added to log]

Other possible causes (not exhaustive) of no shutdown-related information in the errorlog:

a) Errorlog's file system filled before the shutdown
b) Errorlog file disconnected from file descriptor used by ASE.
   For example, errorlog copied to another file, original file deleted, copy renamed.
   A possible hint for this is an unusual lack of entries preceeding the shutdown.
c) Errorlog could have been edited to remove information.

You've heard that SAP ASE 16 offers significant new functionality to boost speed and scalability as we've shared benchmarks supporting this claim in previous blogs.  And in case you missed ISUG-TECH, the China Academy of Railways folks described their constantly growing ticketing system, processing 3+ billion transactions a day and praised the scale-up functionality in SAP ASE 16 - achieving linear scalability with the new release in their physical environment.  Today, I'm excited to share new test results that show SAP ASE 16 scalability in a virtualized environment.

SAP ASE 16 has been tested on VMware Vsphere 5.5, the leading server virtualization platform and the results prove once again that SAP ASE delivers excellent scalability.  In a VMware Vsphere environment using RHEL 6.x, SAP ASE achieved linear scalability with high performance throughput with absolutely zero tuning of the database - I know....I know.....I am not saying there is no need for SAP ASE DBAs anymore.....it is just that SAP ASE is getting more efficient and it has learned to do self-tuning.  SAP ASE scaled linearly from a 16 core environment to a 64 core environment with high performance throughput as the CPU count increased. 

The table and the graph below show the normalized values obtained during the testing efforts.  We think these results are just additional proof of the scalability and speed benefits you can gain with SAP ASE 16.  We hope you agree.

Well.....what are you waiting for.....try it out for yourself along with the many other cool features in ASE 16!!!!

How often in your career do you have a chance to dismantle the old architecture in its entirety and build it again - completely redesigned?  Usually, a company upgrades the hardware once in a three-four years cycle, while the "backbone" architecture outlives the hardware upgrades and lives dozens of year intact.

I have been "lucky" to work for a company long enough to rethink its backbone DBMS architecture twice:  once about ten years ago, when I transformed an old asymmetric architecture into an elegant Warm Standby topology (SAP Sybase Replication Server).  This later grew into a heterogeneous replication topology spanning 7 DBMS systems, some ASE others MSSQL, replicating transactions seamlessly across distant cities.  Now this is the second time I will have a chance to transform the "backbone" of the site:  from active-passive WS topology to an active-active MSA architecture.

Once WS was a thing to contemplate with satisfaction:  simple to setup.  Simple to maintain (although I did have to build a couple of tools to make the administration more failure-proof).  It has proven itself to be vital and stable - close to 10 years of stability - don't remember any failures that resulted from architecture shortages. It was the most simple and elegant alternative for a site that loos for a solution with two available ASEs which may be exchanged without much hassle (I discount storage replication here, which too has its advantages - although its architecture today bears similarity to DBMS transactional replication).  Today, warm standby is bulky, constrained, somewhat out-dated alternative, suffering from SPF which needs to be taken care of by out-of-the-box solutions.  Especially when compared to an alternatives available around - from the same vendor.

As opposed to it, today MSA replication is considered a "piece of cake."  It is easy to setup.  Easy to maintain.  It gives you most of the things WS has given you once ago, and with much simpler setup. More than that, it is possible to integrate warm standby as a single logical unit within MSA topology - for those in love the the logical connection concept.

In the coming weeks I will be privileged to witness a live transformation of the old good warm standby topology into a new MSA-based topology.  Good by my old good friend - I loved to work with you for years.  Loved the stability of it.  Loved the advantages it gave once.   Welcome my new acquaintance.  I hope I will live to love you even more.

It has been quite a challenge to think through the architectural redesign.   How do you move the heterogeneous replication with 7 sites, some MSSQLs, to an MSA solution with minimal downtime (seconds alone)?  As of replication server documentation, the same ASE instance cannot participate in different replication server domains.  Not to say that different replication server domains cannot interact or exchange transactions.  A tale to be told.  But this is over now.  This coming weekend the ground will begin to move:  the old good pair of M5 servers hosting a set of 15.7 ASEs with a logical axis of 24/7 DBMS instances that distributed data down the stream will start to merge into a brand new pair ot T54 servers hosting a set of 15.7 ASEs united in an MSA replication topology, including a pair of IMDB replicas.

I count myself to be really lucky to be able to push the architecture once again to the forefront of DBMS (and HW) technology.   In-memory computing today is something that begins to knock on every door (though few still trust the technology or see its full potentials).  Active-active topology too today is something the customers require more and more consistently.  Every company today requires its DBMS systems to be available 24/7, to run queries super fast, and to require little to no DBA intervention to "fail-over."  IMDB allows you to do things you have stopped to dream about long ago with a ridiculous ease (I don't know of any other DBMS solution that has been as seamlessly integrated into a DBMS product as IMDB - big thumbs to SAP/Sybase product engineers - lovely solution).  I have been able to relieve customer's pains strained to meet deadlines waiting for nasty reporting jobs running historically over hours and days with the help of IMDB.  We are talking about cutting time from over 48 to 2 hours and less.  IMDB is fast - too fast sometimes.  Close to zero downtime and close to zero SPF solution is catered by MSA (with all the advantages and disadvantages of transactional replication).

To cut things short - if you have the guts and the vision it takes about 20 minutes and a set of simple, non-intrusive steps to upgrade your whole architecture from warm standby to an active-active MSA topology...  If you wont dream - you wont learn to fly.

Pff....   20 minutes in a lab....

In the real life with TBs of data and site scattered miles away it will take as many hours...

Days?....

Time will tell.

ATM.

Join us for the UK launch of the SAP Data Management Forum, where we can't wait to tell you about the latest SAP Data Management solutions with new capabilities to solve your most demanding data management challenges.

You’ll hear about SAP’s vision and roadmap for data management solutions, including SAP ASE, IQ, ESP HANA etc. that offers revolutionary opportunities to your business while requiring a fraction of the IT infrastructure and an evolutionary path for your applications.

To Register please click http://events.sap.com/gb/sap-data-management-forum/en/home/

• ElapseTime = CPU Time + WaitTime

A crude form to account for CPUTime would be something like this

• CPUTime = Time to perform LIOs + Time to Parse and Compile + CPU Spins because of spinlock contention

Now from monProcessActivity we do get CPUTime + Logical IOs for a given SPID.

We had a number of challenges when we converted our servers to ASE157 with respect to performance. We had extensive data collectors and had minute by minute deltas for monProcessActivity. From this data we started analyzing the LIORatios for different applications (program_name). We noticed that for some of the applications the LIORatio was very low.

On investigation we found the following:

• The parse and compile times for some of the high frequency queries was way high and this is the reason for the low LIO Ratio

Now this begs the question as of why the parse and compile times are high.

• We do use statement cache for all servers
• However we have disabled statement cache for queries with temp tables (TF- 467)

Here are the reasons why statement cache would not effectively

• Data type mismatch
  • insert into myTables (col1,col2) values(1.0,1.1)
  • insert into myTables(col1,col2) values(0,0)

          In the above example the statement cache engine does not know the datatype of the columns when it is caching these statements. So based on the literal values passed it will created different sets of statements in the cache. For some of the table with many numeric columns we see that the number of cached statements was higher than 10000. It means the reuse count of the cached statements is very low.

• Literals in the select clause
  • select '123' as col1 from myTable
  • select '234' as col2 from myTable

     Though 'auto literal parametrization' is turned on if there were to be a literal in a select clause it does not convert such literals into parameters

• Literal parameters in derived tables
  • select * from (select '123' as col1 from myTable) a
  • select * from (select '234' as col1 from myTable) a

     The literals in derived tables as shown above are not parameterized. So there will 2 different statements in the statement cache

• LIKE clause
  • select * from emp where lname like 'GP%'

     In this case too the literal is not parametrized

• TEMP Tables (TF - 467)
  • This is an interesting case. When you too many short lived connections which use temp tables then TF-467 is something you may want to consider.
  • If the connections you have to the dataserver persist for too long then TF-467 can hurt you

In conclusion the parse and compile time for queries in ASE157 can be signficantly higher than the older versions. Statement cache usage is imperative to good performance. However need to be cognizant about the scenarios where statement cache would be not effective.

LIO Ratio is a good way to start investigating some such problems.

We have also used LIO Ratio to solve some of the issues with with spinlock contention and will discuss about this in the next post.

On Demand Technical Webcasts Feature New Capabilities in Latest Release

We’ve just concluded a very successful 5-part webcast series on SAP ASE 16.  The series covered the new features in this latest release and described in detail how customers can benefit from the new capabilities.  All of the webcasts are now available for viewing.

SAP ASE 16 Webcast Series On Demand

1. Overview of SAP ASE 16 and Future Directions
2. Achieving Linear Performance Scalability in Large Multi-core Systems with SAP ASE 16
3. Extreme Transaction Processing: Ensuring Competitiveness & Agility in a World of Constant Motion
4. Simplifying Development and Management in SAP ASE 16
5. Security and Auditing in SAP ASE 16

For additional resources on SAP ASE 16 check out the SAP ASE 16 launch page:    http://fm.sap.com/ase16/

Hey,

Whoever submits a google search for SAP & SIMPLICITY will find himself/herself showered with conflicting opinions:

• SAP & Simplicity?  Prffff.  Give me a break....
• SAP & Simplicity?  Yeah!   SAP embraces simplicity as a way of thinking!....

I have been exposed to some of SAP application packages.  From what I have seen there still are things to simplify or modernize.  This is my "novice" opinion only.  Haven't been exposed to it for a prolonged period of time.  But I know of at least one subset of SAP application package where simplicity has always been a status quo.  And as for my opinion - the situation in this sector has improved even more with the latest releases.  I am talking about SAP Sybase portfolio, as you might have guessed.

I have just finished a very intensive week of working on a project of moving a 24/7 site from an old architecture that relied on a bunch of replication servers (15.0, 15.2 - Warm Standby, Replicate Sites with & without rep agents) connecting 7 heterogeneous sites (ASE&MSSQL) to a new architecture connecting the same heterogeneous sites - but in a simplified and more robust manner (MSA - flat and simple).   Whoever has had a chance of working with Sybase Replication server in its pre-MSA versions probably still remembers the hard work he or she has been subjected to.   True, it has not been SO difficult to manage, but for a topology with over 2k tables, managing subscription to numerous replicated sites has been quite a challenge.  In order to make my life easier I have built a dedicated software to embrace all the flexibility the environment I was responsible for required.  It has been a great fun still (both writing the tool and managing the site).  Replication server in those versions still has been pretty well worked out to allow an organization to run 24/7 unimpeded.  Warm standby as the central axis (to manage heavy administrative tasks and basic DR requirements, for example).  Ability to attach standby of the flight.  Efficient transaction-based replication.  It has been very stable to run a decade without a single failure.

Still, the setup has been lengthy and cumbersome.  Waiting for 2k replication definitions to be built (and WS needed it as well for more efficient communication between active and standby sites)... Waiting for 2k-x-sites subscriptions to get defined...  The setup (leaving aside the dump/load sequence) has been a matter of hours.

No longer.  With MSA and 15.7 RA and RS releases the whole setup for a multi-site replication topology is a matter of minutes.  If your systems are synchronized and all you are required to do is to setup replicated topology - the time you need to set everything up is the time it takes you to run a short list of SQL commands against your replication server.   If you are diligent enough to set up POC version of your topology, generate and save all the scripts, and then run the same scripts (easily changed) to set up you real environment, the whole thing fits neatly into a couple of minutes.

I really have to express my gratitude to SAP Replication Server engineers.  Loved the software once - it has been very stable and flexible.  Love it even more now - it has added a true flavor of simplicity to it (never used GUI setup though - so I cannot comment on it).

If other software packages from the same house have been as simple to set up and manage, I thing there has been much less disagreement about SAP & Simplicity.  As far as SAP Replication Server 15.7 is concerned - simplicity IS one of its strong features - without compromising stability or flexibility.  I do not know how simple it is to manage replication to/from SAP HANA, but to manage replication to SAP Sybase ASE IMDB in-memory DMBS is a piece of cake (another gem from the same house).

Been there.  Done this.

KITS.

Keep IT Simple...

My appreciation for that.

ATM.