SAP ASE 16 SP02 Performance Features

SAP ASE 16 SP02 Performance Features
Reinoud Reynders (UZ Leuven)
Ashok Swaminathan (SAP)
January 2016

© 2015 SAP SE or an SAP affiliate company. All rights reserved. 2Internal
SAP ASE 16 SP02 Performance Features
• Overview of SAP ASE 16 SP02 Performance Features
• Case Study - Uz Leuven Experience With ASE 16 SP02

Disclaimer
This presentation outlines our general product direction and should not be relied on in making a
purchase decision. This presentation is not subject to your license agreement or any other agreement
with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to
develop or release any functionality mentioned in this presentation. This presentation and SAP's
strategy and possible future developments are subject to change and may be changed by SAP at any
time for any reason without notice. This document is provided without a warranty of any kind, either
express or implied, including but not limited to, the implied warranties of merchantability, fitness for a
particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this
document, except if such damages were caused by SAP intentionally or grossly negligent.

Overview of SAP ASE 16 SP02 Performance Features

SAP ASE Investments In High Performance
Version Features Benefits
15.7 • ASE In-memory Database (IMDB) - entire database in
memory, but without support for durability of transactions
• Typical usage : IMDB as temp DB or use of IMDB for fast
computations without the need to persist changes
• Performance increase by 2X (up to 10x in some customer cases)
16.0 • Run Time Logging Enhancements (Buffer Unpinning)
• Metadata Management Enhancements
• Lock Management Enhancements
• Allowed scale up beyond 32 cores (up to 80 cores), near linear
scaling
• Achieved over 1 million/minute business transactions
16 SP02 • Compiled Queries
• Transactional Memory
• Lockless Data cache
• Latchfree Btree
• Non Volatile Cache Management
• Latency and Throughput benefits
• Investments starting from ASE 15.7
• Early vendor to introduce In-Memory technology
• Continued focus with each release

ASE 16 – Start Of High Performance Focus
0
500000
1000000
1500000
16 32 48 64 80
Scale-up Performance
Transactions per
minute
> 1 million tpm
Engines
Environment
SUSE Linux Enterprise Server 11
Platform: 8 sockets/80 cores Intel® Xeon® E7-
8870@2.40GHz with 1TB RAM
Feature Description
Scale up on large SMP
systems
• Minimize locking/latch contention, in highly concurrent environments
• Enhancements in the area of run time logging optimization, metadata management, lock management
Partition level Locking • Granular locking for partitioned table
• Enables Concurrent DDL and DML operations on a table
Dynamic Thread
Assignment
• Allows executing query plans in parallel with fewer resources/threads
• If # of threads < work units, threads completing execute remaining tasks
Index Compression • Index compression enabling storage savings for large indexes
• Completes current capabilities - data compression (row/page), LOB, backup
Optimized Star Join
Queries
• Allows hints in the join syntax
• Can use the syntax “plan (use fact_table tablename)” –query processing optimizations related to star join

SAP ASE 16 SP02 – High Performance Features
To Be Developed
T/SQLJDBCODBC
XOLTP QP
Parallel Dynamic ThreadingCode Compile
MVCC
In-memory Row Store
Main Memory
Lockless Metadata
Transaction
Memory
Kernel Threading
Disk
Flash Disk
Upcoming New In SP02
Buffer Cache
Scripts
Available
Latch Free
BTree
Lockless
Data Cache
Simplified Native Access Plans (Compiled Queries)
• Compiled query plans – faster execution
• Transparent to applications and users
Latchfree B-Tree on Indexes
• Reduces contention
• Increases concurrency and performance
Lockless Buffer Manager
• Decreases cache contention
• Increases concurrency and performance
Transactional Memory
• Minimize contention leveraging hardware for identifying memory
conflicts
Non Volatile Cache Management
• Leverage SSD for storing frequently accessed/updated pages
Latch Free BTree
Lockless Data
Cache

Simplified Native Access Plan (SNAP) - Overview
A new query plan execution feature
 Avoids repetitive query exec code generation from the physical
operators output from query optimization
– Works on
o Cached SQL Statements in statement cache
o Statements within stored procedures
o Fully prepared SQL statements
Available on x86-64/amd64 Linux
Transparent to the user
Enabled by configuration parameter;
ASE uses SNAP automatically when possible.
Unsupported plans continue to use lava execution engine.
SELECT  {column list}
FROM  table
COND1  due_dt <=getdate()
COND2 (AND)  recv_date is null
SELECT  {column id’s & datatypes}
FROM  objid=123456
COND1  col_id=3 (dt) >= (dt) ‘Jan 1 2015’
COND2 (AND)  col_id=4 (dt) IS NULL
SQL Parsing
Normalization
Pre-Processing
Query Optimization
Native Access Plan (Query Exec Code)
Query
Compilation
TDSLANG  select * from table where
due_dt =getdate() and recv_date is null
Receive Buffer
Query Execution
Query
Execution
SNAP

Latch Free BTree
 Latch is used to ensure physical
consistence of page between DMLs
and query.
 Minimize contention where SH_LATCH
and EX_LATCH block each other, when
multiple threads need to synchronize
between each other when
modifying/reading index pages
 Logical lock semantics not changed
BLOCK
page
Query DMLs
SH_LATCH EX_LATCH
Select * from customer where money > 5000 Insert into customer values(6000)

Lockless Data Cache
Cache Contention
Access to pages in named caches are through hashtables. Spinlocks protect buckets in named
cache’s hashtable.
Contention on cache spinlock can be resolved by
 Moving object(s) to separate named caches
or
 Partitioning the cache
For example, lockless data cache can help when there is significant contention on a single cache
partition but not significant contention on other cache partitions
This means less waits and spins on spinlocks, and thus lower contention. In turn lower CPU
utilization, higher performance and improved scalability

Transactional Memory
Objective:
 Increase concurrency (and minimize contention) by leveraging hardware for tracking memory conflicts as a
result of concurrent execution of code
 Background
– Spinlock (used to protect certain data structures) has been fragmented and distributed in the ASE code
– Contention is on Lock
– Many times, not on actual data which we want to protect
Solution
 Allow multiple threads to modify data structures, unless there is conflict at memory level
 Newer hardware from Intel (Haswell-EX/Xeon E7 V3 processor), and IBM (Power), keeps track of memory
reads/writes and memory contention
 By allowing concurrent processes to modify memory, and undoing the offending process/thread when there is a
memory conflict, concurrency is increased

Non-Volatile Cache Management
DB ACCESS/STORAGE
Buffer Manager
DISK
• SSD cache will act as a intermediate storage.
• Buffer manager reads pages from disk (cold pages)
• Hot and warm pages that cannot fit in Buffer manager will be
evicted to the SSD cache.
• Pages which are dirty will also be shifted to the SSD cache.
This dirty pages then will be written in a delayed manner to
the HDD disk.
• Frequently read pages will be in SSD
SSD CACHE
XOLTP

UZ Leuven
• The largest healthcare provider in Belgium
• 1955 Beds
• 9000+ Employees
• Centralized IT dept.: 145 staff
• 55 Infrastructure & operations
• 73 Patient – related software development
• 17 Admin/logistics software development

Clinical Workstation (CWS/KWS)
• Electronical medical record:
• Patient mgmt., planning, order entry, e-prescriptions, bedside scanning, drug-drug interactions, lab
results, …
• Consolidated workspace for physicians, nurses, GPs and patients
• Development started in 1988
• Release cycle: 1 release/week

KWS Infrastructure
• Mostly 2-Tier
• Database:
• 20.764 stored procedures (1.123.544 lines)
• 4.411 triggers (309.275 lines)

Nexuz Health
• 19 other hospitals (will) use our medical file system (the Clinical Workstation, CWS)
• 1 instance, 1 shared medical file per patient

Advantages - Medical
• One group of hospitals with the same procedures, the same quality proposal
• Bring the care closer to home
• Patients can transparently be referred between these hospitals
• Pooling of knowledge
• Transmural clinical pathways
• Clinical trials

Nexuz Health Service Points
9643 beds total (37% of Flemish hospital beds; will grow to 45%)

Expected Growth
• Current situation
• Partner complexity per bed: 30% of UZ Leuven
• Many partners waiting for startup
• Expectations next 24m
• New partners startup
• Partner complexity per bed -> 50%
• Need to grow 50% in less than 2 years

Expected Growth: Example e-nursing
#registrations
#plans
18
months
36
months
6
months

1 Shared Database
• Ergo: huge system, catering for +8000 bed
• +25.000 named active users / 6.000 simultaneously (/3 min
• 85M transactions per day / 8.000 processes sim/3m
• 150K rows inserted|updated|deleted/sec
• Database size: 12 TB
• Cache size: 140GB
• Cache hit ratio: >99%
• One of the largest worldwide
• 24/7/365 operation

Scalability: Today’s Utilisation
Avg % (CPU busy + I/O) utilisation (64 engines):

Challenge: Scalability
• Current ASE 15.7 SP130, threaded mode with 64 engines
• Better scaling in ASE 16.0, even without the new mem scale options

UZ Leuven Benchmark Test
• We take the top 1400 queries with parameters from production
• We use real data (copy of production)
• Try to execute as many as possible transactions in 5 min time (use different engines)

UZ Leuven Benchmark Test

Extreme Scalability
X 8

One Of The Challenges For Our Growth: Spinlock
• We have status tables that are used by everybody everytime
• The status, the basic info and pointers of the current patients.
• The status of each patient in a specific physical location
• This info is always in cache (important!) but is dynamic and it’s there where locking occurs
• Solution: lockless data cache

Lockless Data Cache
• If we take the top 1400 queries:
• Some have advantage, others not
• Depends on the size of the table/data, is there cache contention or not?
• If we take queries in the top 1400 where lockless data cache fits well (smaller hot tables):
• Select our status tables: we know our application and we know they can have an issue and are relative
small.:
• Tables with a high amount of logical IO: detect by monOpenObjectActivity
• Some examples: x#chemoVersieStatus : 60 000 rows , 2 MB / x#chemoSchemaDefinitie : 145 000 rows : 100 MB
• Performance gain 3 times!!!

Improvement Using Lockless Cache
0
50
100
150
200
250
300
350
One top query 1000 queries Status tables
"normal" cache Lockless cache
3 x
+5 % +11 %

Conclusion
• With SAP ASE 16 SP2
• We can grow more than 8 times
• Reducing of spinlocks
• Perfect architecture for extreme transactions
• 100 % adapted for multicore and multi thread hardware
• With high performance features in SP02
• A big benefit in general
• For lockless cache we see improvements of 3x better performance.
• Will give us less locking issues, better performance but more important: better scalability

Reinoud Reynders
Reinoud@uzleuven.be
@reinoudreynders
Ashok Swaminathan
ashok.swaminathan@sap.com
Contacts

SAP ASE 16 SP02 Performance Features

In this document

More Related Content

What's hot

Viewers also liked

Similar to SAP ASE 16 SP02 Performance Features

More from SAP Technology

Recently uploaded

SAP ASE 16 SP02 Performance Features