Вы находитесь на странице: 1из 48

run()

DMM214 Application
Enhancements Using SAP ASE
Encryption and In-Memory Features

Public
Speakers

Las Vegas, Sept 19 - 23 Bangalore, October 5 - 7 Barcelona, Nov 8 - 10

Jeff Tallman Matthias Wild Jan Stallkamp

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 2


Disclaimer

The information in this presentation is confidential and proprietary to SAP and may not be disclosed without the permission of
SAP. Except for your obligation to protect confidential information, this presentation is not subject to your license agreement or
any other service or subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this
presentation or any related document, or to develop or release any functionality mentioned therein.

This presentation, or any related document and SAP's strategy and possible future developments, products and or platforms
directions and functionality are all subject to change and may be changed by SAP at any time for any reason without notice.
The information in this presentation is not a commitment, promise or legal obligation to deliver any material, code or functionality.
This presentation 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. This presentation is for informational
purposes and may not be incorporated into a contract. SAP assumes no responsibility for errors or omissions in this
presentation, except if such damages were caused by SAPs intentional or gross negligence.

All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially
from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only
as of their dates, and they should not be relied upon in making purchasing decisions.

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 3


Agenda

Full database encryption


Implementing
Index Compression
Tips & Tricks
MemScale Features
SNAP
NVCache
Latch-free B-Tree
Lock-free Buffer Manager

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 4


Full database encryption
securing data at rest.

Public
ASE supports 2 data encryption capabilities

Column encryption
The most secure method
Data is encrypted in memory and on disk
Different data columns can be encrypted with different keys
Protects from unauthorized access - from external users as well as system users without rights to the data
Including credit cards, where public can insert but only finance users would be able to read
Users without decrypt permission get a mask value back (e.g. ###-##-####)
Indexable for search parameters, etc.
Problem with SAP Business Suite
SAP uses a single DBMS login (SAPSR3) - so essentially only provides protection at rest from external users

Full database encryption


Protects data at rest (from external users)
Least impact on query performance
Easiest to implement
2016 SAP SE or an SAP affiliate company. All rights reserved. Public 6
Column encryption in ASE

Column Encryption (ASE 12.5.4 and later)


Totally secure encrypted on disk, in memory, in log, etc..
Each column can be encrypted with separate keys
Assumes different users with different access requirements
Prevents inadvertent disclosure to authorized users of system but not
authorized for data
Column decrypt permission with data masking (unique to ASE)
e.g. ###-##-####

Impacts on performance
Good news: Indexable encryption for Pkey and Fkey columns
Works extremely well on account numbers, employee
Unique to ASE vs. Oracle and other competitive implementations id, SSN, health test results, etc. (equi-SARGS)
Bad news: Doesnt work well on Date of Birth, Last Names, etc.
Range queries (due to ciphertext sorting) due to range queries nor also on ORDER
Blocks compression effectiveness (if a SALT/IV is used) BY/GROUP BY columns that are indexed. The issue
is the query performance will suffer as index is not in
Certified with SAP applications.but. value sorted order - it is in ciphertext sorted order.
Result is we have to scan and decrypt entire index.
Only provides disk level protection as SAP uses common login
2016 SAP SE or an SAP affiliate company. All rights reserved. Public 7
Full Database Encryption

Full Database Encryption (new in ASE 16)


Provides protection for an entire database, WITHOUT affecting
existing applications
All data, indexes, and transaction logs in database are encrypted
Backed up database in encrypted form
All authorized database users can see data
No impact on range queries or compression
Encryption is at page level
as pages are written to disk, and decryption before they are loaded into
memory
Will be after/before Compression/Decompression
Can be used with column encryption
Dual key control with automatic startup

Can be implemented online w/o user impact


Can be suspended/resumed for long run times
Can be used to encrypt existing or new databases

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 8


Database Encryption

Uses Database Encryption Key to encrypt a database symmetric key


User has to create the key before database encryption
create encryption key key_name [for AES] for database encryption
[with {[master key] [keylength 256] [init_vector random] [[no]dual_control]}
Default is init_vector random (mandatory)
Example:
Create encryption key test_key for database encryption with master_key
Create encryption key test_key for database encryption with dual_control

Master key and dual master key will be used to protect test_key

Create database with encryption


Create a new encrypted database
Create [temporary] database database_name encrypt with key_name

Alter an existing database to be encrypted


Alter database databae_name encrypt with key_name

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 9


Notes about full database encryption

Fully online operation


alter database <database_name>
User queries and DML are not affected
{[encrypt with <key_name>
| decrypt [<with key_name>]]
Can be paused/resumed [parallel <degree_of_parallelism>]
and at times, it needs to be | resume [encryption | decryption
[parallel <degree_of_parallelism>]]
Why would you pause: | suspend [encryption | decryption] }
Database backups (including incremental)
Shut down the server (for maintenance or static config changes)
others (see documentation)
Database encryption is implemented within the server
Anything that reads the raw pages needs to pause encryption (e.g. backup server)
If the server is going to have an outage, you should pause encryption first
It will recover from a crash, but kinder/gentler operations avoids problems

Backup master database


Ideally, you should be doing this every day anyhow
Database Encryption Keys are kept here.
You lose masterand you really lost the data
Especially if you didnt do the key recovery steps ahead of time

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 10


Full database tips

Physical IO performance will be up to 3x slower


Biggest impacts
Transaction log writes
Query reads - including reads that cause writes due to cache MRU/LRU
To offset, consider
Increasing memory available for data cache
Using SSD for high write devices (e.g. txn log)
Avoiding slow RAID levels (e.g. RAID 6)

Implement on ASE after migration is complete


Otherwise, migration will take a lot longer

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 11


Index Compression
Tips & Tricks.and what not to do.

Public
Index compression basics

Most DBMSs use a common row format (both for data and index)
Optimized for disk storage by minimizing overhead (especially in col offset table)
Row header, fixed length cols, variable length col data, variable length col offset

Index compression problem


Compressing each column not too effective as
would need multiple compression/decompression steps (one for each column)
Would offer no compression on single column indexes
Best alternative is prefix compression
Sort index on the longest prefix possible and compress the combined prefix as a singe entity
Requires storing the row in column order - which adds to the col offset table (for fixed length cols)
This can result in space explosion if not too careful as each fixed length now adds 2 bytes to rowsize

Row Status #var Length Variable col offset


Fixed Length Cols Variable Length Cols
# Bits len col var cols table

Row header 2 bytes One entry per var length col


(2 bytes each) (2 bytes each)

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 13


Compression/Decompression and performance

Compressing/Decompressing data impacts 200K row table scan (~7MB)


performance
CPU time spent doing the compression 150

Scan time (ms)


Memory allocation to hold uncompressed values 125
100
Spinlock/mutex contention on memory allocations
50 50
Data compression optimization
Attempts to use index leaf values for uncompressed 0
data vs. decompressing data Compressed Uncompressed
Obviously, this doesnt work well when index is Note that since table is fully
cached, the time is 100% cpu time
compressed.
This was the TOADL table in a SAP ERP
system which was table scanned multiple
times per minute due to lack of indexing
supporting the polling query

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 14


Tips for index compression

Implement per index vs. table/database wide

Dont compress small indexes (<100MB)


Even on large tables (e.g. look at index space consumed)

Compressing single key indexes on numeric & date datatypes on little endian systems might not
work
It will only work if there are a lot of repeating values (same exact date) and not sequences or similar with
slight differences
This is due to the fact that byte swapping places the more volatile bytes as the leading bytes
Big endian series 100001, 100002, . 0x000186a1, 0x000186a2 (prefix compression works well)
Little endian series 100001, 100002, . 0xa1860100, 0xa2860100 (prefix compression doesnt work well)
Business Suite tends to store dates as YYYYMMDD character format, so dates may not be as affected.

Take a cautious approach even on large tables


Test/observe the impact on queries with expected concurrency
Use MDA monOpenObjectActivity and compress indexes with the lower UseCounts first
Compress Pkey/Fkey indexes last - if at all
2016 SAP SE or an SAP affiliate company. All rights reserved. Public 15
MemScale Features
.and where exploiting them makes sense with Business Suite

Public
Business suite and query execution
Business Suite has a few query execution characteristics to consider
SAP does a lot of client-side joins using query blocking is used with thousands of repeated query executions to
satisfy large IN()/UNION lists
E.g. first query retrieves a list of 1000 orders - then iterative queries are used to fetch the order details
Even ERP systems tend to be very read heavy - e.g. 90-95% reads in read:write ratio
Business Suite indexing often is not aligned with query predicates consequently the above is actually
substantially higher
Logical Reads:Physical Reads 30:1
Logical Reads:Physical Writes 5000:1
Due to Central Instance and other factors, ASE often has less than 50% of memory on host

Net net:
Very high execution counts of commonly used queries
High cache volatility of key large tables in most cases
Very low index volatility
Uses a lot of locks

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 17


ASE MemScale option (included in ASE Runtime for Suite on ASE)

Simplified Native Access Plans (aka SNAP)


Referred to as compiled queries
Reduces query execution times by avoiding query exec plan generation

Latch-free B-Trees
Reduces index latch contention between readers and writers

Lockless Buffer Manager


Reduces CPU due to mutex/spinlocks on cache MRU/LRU for very highly cached data volumes

Non-Volatile Cache (NVCache)


Extends memory to SSD devices to reduce physical reads/re-reading of common data

Transactional Memory
Exploits chip level hardware instructions on x86 when modifying linked lists in internal DBMS operations
For ASE, this is the lock list as well as data cache MRU/LRU
2016 SAP SE or an SAP affiliate company. All rights reserved. Public 18
ASE MemScale and Suite on ASE suitability/applicability

MemScale Feature Applica- Platform Comments


bility
SNAP (compiled query) Linux x86/64 Definitely should be considered

Latch Free B-Tree All Unlikely to benefit due to low index contention except
perhaps on isolated tables (workflow queue)

Lockless Buffer Manager All Depends on memory for ASE. If >99% cache hit ratio
and cache volatility <5% of cache, it might benefit

NV Cache All Most likely will benefit - mutually exclusive with the
above (lockless buffer manager)

Transactional Memory Linux x86/64 on Use it if you have itjust do it already.


Haswell EX+

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 19


SNAP (aka Compiled Queries)

Similar to a JIT for JAVA Receive Buffer


TDSLANG select * from table where due_dt
Avoids repetitive query exec code generation from the =getdate() and recv_date is null

physical operators output from query optimization SQL Parsing


SELECT {column list}
Works on FROM table
COND1 due_dt <=getdate()
Cached SQL Statements in statement cache COND2 (AND) recv_date is null
Statements within stored procedures Normalization
Fully prepared SQL statements Stored Procs, SELECT {column ids & datatypes}
Query FROM objid=123456
Stmt Cache, Compilation COND1 col_id=3 (dt) >= (dt) Jan 1 2015
Prepared Stmts COND2 (AND) col_id=4 (dt) IS NULL
Shortens code execution path SNAP

As soon as statement is identified, it simply loads the Pre-Processing


previously saved Query Execution Native Access Plan
Query Optimization
Query identification
SQL Hash code found in statement cache Native Access Plan (Query Exec Code)
Query
Subsequent exec of a statement in a stored proc Execution
Query Execution
Subsequent exec of a fully prepared statement

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 20


SNAP Tips for Suite on ASE

Extremely good fit:


Very high query execution repeats due to query blocking factors, client side joins, etc.

Key problem:
Only available on Linux on Intel x86/64
Reason is that the technology stems from HANA

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 21


Index Latches with DOL tables

Latches added for DOL index pages


Prior to DOL locking (1998), ASE used locks on index
pages which were held the entire length of the
transaction
These index locks were the single largest source of
contention and deadlocks

Non-transactional Latches
With DOL tables, a process grabs an non-
transactional latch only long enough to read (shared-
latch) or modify (exclusive-latch) that index page and
then releases it
In the nearly 2 decades (!) since, transaction volumes
are now in the XOLTP range and these latches now
cause the same level of contention as locks
previously.

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 22


Causes of Latch Contention
Monotonic Index Keys
For example trade_date (or any datetime that only increases) or sequence numbers (IDs)
The problem is similar to a heap table with all the insertions happening on the last page
Only in this case it isnt a heap table - the index is sorted - it is just that the new values are all constantly increasing so
they all go to last page

Concurrent Writes to Same Index Value


Remember, with nonunique indexes, with two rows with identical index keys will not have two leaf rows.
Instead, a single index leaf row is created with a RID list of all the matching rows.
Consequently highly concurrent writes would be contentious.
A good example would be low cardinality indexes with a lot of skew (e.g. an index on job_status)
Remember it is not the cardinality in real life, it is the cardinality in the database - so city+state could be an issue
where customers are largely regional

Read/Write conflicts
Reading an index page uses a SH_LATCH
Writing an index page requires an EX_LATCH
So indexes with heavy range scans could impede writes if index keys have a lot of inserts/modifications

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 23


Latch-free B-Trees

Latch-free B-tree
Index modifications are done in-memory using a delta merge
process and CPU atomic instructions
Each database has a separate mapping table
Memory table to track index page modifications
Memory table pointer points to most current page mod
After 16 mods, page is merged back into single page
Reads do not need latches at all (SH_LATCH)
Writes will still use an EX_LATCH V2
V3
V4
V5
When to use
monProcessWaits, monSysWaits shows a lot of waits on
WaitEventID=41
Or monProcessWaits on key apps/processes
Indexes that have high inserts with a monotonic last key (or only
key) or low cardinality - with high LIO
E.g. trade_id or any single key index on sequential #s
Trade_date or txn_date as last column in index
Use monOpenObjectActivity.RowsInserted & LogicalReads

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 24


Where Latch Free B-Trees help

Write/Write conflicts NO!!


Monotonic key inserts with concurrent users
Nonunique key value inserts into RID list (e.g. Status)
In fact, it can be a bit worse as latch has to wait for version creation
Best solution is to re-index very low cardinality keys
e.g. {status} {status,date}.or better yet. {status,date,<suser_id()>)

Read/Write conflicts YES!!!!


Hence we look for indexes with high volatility AND high LIO
If you think about it, this will likely be a major portion of your contention
Indexes with date - most often queried with date ranges
Indexes with ID - most likely the primary key and used in joins
Indexes with status - likely polled frequently looking for new jobs

Key takeaway LFB reduces latch contention, but doesnt eliminate it.

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 25


Latch-Free B-Tree .so wheres the Trade Off

Nothing is for free.

.Reads might be a tad slower


Without versioning and w/o contention, the read is a fast scan of the intermediate & leaf nodes
With versioning
Reads will need to use the latest (inactive) version to get the value for that key
Essentially a few extra lookups in memory for up to 15 keys at the most

and they might not be either.


Because if there was a lot of latch contention, likely if affected reads as well
Which is slower - latch waits or folding in the versions???

Your mileage may vary


Advice: turn on for individual indexes that really need it - dont use globally
2016 SAP SE or an SAP affiliate company. All rights reserved. Public 26
Latch Free B-Tree Tips for Suite on ASE

Validate requirement
Check monOpenObjectActivity for index
with high volatility (RowsInserted+RowsDeleted)
and very high LIO
Check key process for monProcessWaits where latch contention is very high
Latch contention WaitEventID = 41

Areas that might need it


Queue tables (if status or date is in index key)

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 27


Cache spinlocks

Cache spinlocks are grabbed bufsearch()

Cache search to see if a page is in cache


Moving a page from LRU to MRU Cachelet
Spinlock
Adding/removing a page to cache
Updating the buffer keep count buftoMRU()

to prevent another query from flushing page from cache


while trying to read it

Spinlocks use OS mutexes for implementation Update keepcnt

CPU has to raise memory barrier


The more cores/engines, the longer it takes

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 28


Lockless Buffer Manager

Lockless Buffer Manager (new in 16 sp02)


Can be dynamic for relaxed caches only
-- define a 256MB cache for system tables
Static/default will need a reboot
sp_cacheconfig "sys_cache", "256M",
e.g. default data cache "lockless data cache", "relaxed
Add cache status = lockless data cache to config file
Uses atomic operations for buf keep count & cache hash table
operations
-- edit config file to make default data cache
Hence comments about only working for relaxed data cache refers to -- a lockless cache
fact that only relaxed caches are truly lockless
Eliminates victim pointer/cache replacement for relaxed cache [Named Cache:default data cache]
cache has to be larger than data bound or else performance could be cache size = 70000M
impacted as cache victims could be a bit arbitrary cache status = default data cache
cache status = lockless data cache
cache replacement policy = DEFAULT
When to use: local cache partition number = DEFAULT
monSpinlockActivity shows high spins on default data cache
spinlock (or any cache)
Make sure you delta the samples.
Available on all core platforms in threaded kernel

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 29


Lockless Buffer Manager & Default Data Cache

Converting to Lockless Data Cache


You can only convert relaxed caches to lockless data -- define a 256MB cache for system tables
caches using sp_cacheconfig sp_cacheconfig "sys_cache", "256M",
If converting a strict cache or default data cache "lockless data cache", "relaxed
For named caches, first convert to relaxed
For default data cache, alter the config file
-- edit config file to make default data cache
-- a lockless cache
Warning:
Essentially, the cache will be converted to internally to a [Named Cache:default data cache]
relaxed data cache (default data cache included) cache size = 70000M
cache status = default data cache
Hence you might as well convert a user defined named cache to cache status = lockless data cache
relaxed anyhow cache replacement policy = DEFAULT
You may not want to convert default data cache if you see local cache partition number = DEFAULT
a lot of cache volatility and are seeing a lot of physical
reads
NV Cache may be a better solution
Watch monDataCache for PhysicalReads (after warm-up)

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 30


Lockless Buffer Manager w/ Default Data Cache

1> sp_cacheconfig default data cache


2>go

Cache Name Status Type Config Value Run Value


------------------ -------- ----------------- -------------- ------------
default data cache Active Default, Lockless 2048.00 Mb 2048.00 Mb
------------ ------------
Total 2048.00 Mb 2048.00 Mb
==========================================================================
Cache: default data cache, Status: Active, Type: Default, Lockless
Config Size: 2048.00 Mb, Run Size: 2048.00 Mb
Config Replacement: relaxed LRU, Run Replacement: relaxed LRU
Config Partition: 1, Run Partition: 1

IO Size Wash Size Config Size Run Size APF Percent This was the result of simply altering the
-------- ------------- ------------ ------------ ----------- config file - the default data cache was not
4 Kb 61440 Kb 1536.00 Mb 1536.00 Mb 10 changed from strict to relaxed first, but it
32 Kb 61440 Kb 512.00 Mb 512.00 Mb 10 automatically converted on reboot
Execution time: 0.015 seconds

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 31


Transactional Memory
Programming for concurrency has always required something like mutexes
Mutexes either can be spin (ASE spinlocks) or sleep (ASE does physical & logical locks to avoid these)
Mutexes have high overhead as they require the cpu to raise a memory barrier
Which means coordination with all the other cpus on the host.an expensive process on large core-count machines

CPU manufactures have started to address this problem by adding HW instructions


E.g. Test/set; Compare and Swap (CAS)
These instructions work when only modifying a single memory cell - e.g. a counter
Allows memory values such as counters (e.g. keep counts, etc.) to be modified without spinlocks ASE 16
Transactional memory
These instructions work when modifying multiple memory locations
Allows list contents to be changed without a spinlock

Transactional memory only available in recent CPU cores


X86/64 Haswell EX (not v1)
IBM Power8, etc.

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 32


Transactional Memory and ASE
One use case is lock spinlock contention
Adding/removing entries on lock chain required grabbing spinlock
Searching for entries required grabbing spinlock to avoid writes
while reading

Second use case is buffer management (MRU/LRU)


Not mentioned in docs, but it is there.

When to use:
monSpinlockActivity shows a lot of spinlock contention on
fglockspin, tablockspin or address spinlock

First things to try


Increasing lock hashtable size
Decrease spinlock ratio
Increase ELC/engine lock transfer

Enable transactional memory


Only available on Linux for sp02

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 33


A common pain point with any DBMS

The miserable fact of life with large data volumes and analytical queries
Query execution often results in large work tables in tempdb
Huge impact on cache contents
Often spills to disk typically a SAN on the other side of a [slow] HBA adapter
4-8Gbps, 250 concurrent IOs, etc.
.which then fills SAN cache, which then spills to really, really slow disks
Query execution often requires scanning large data volumes
Again, impact on cache contents as other tables/pages used for other queries pushed out of cache
Typical drill-down and other subsequent queries on dimensions often hit the same pages
.but either couldnt fit in cache.or were pushed out by another query

Typical solution move entire database to SSD in SAN


Unfortunately, very expensive due to high cost of SSD in SAN
Doesnt resolve the IO bottlenecking on HBA especially for tempdb (work tables, sorts, etc.)

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 34


SSD Buffer Extension: Reduce/Eliminate cache flush

A common DBMS problem

Competing user queries


High cache volatility due to large
volumes of data being re-read
repeatedly
Slow performance as re-reading the
same data requires physical reads
from slow SAN disks Cache Cache Cache Cache Cache Cache
10s of ms replace replace replace replace replace replace

NOT a candidate for lockless data Cache Cache Cache Cache Cache
flush flush flush flush flush
cache

SSD Buffer extension


PCIe SSD can be large enough to
cache almost entire SAP database

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 35


Lets have some fun (thanks to EMC)

All Flash Arrays vs. PCIe SSD


PCIe SSDs have much faster access speeds due to bus speed vs. HBA
All Flash Arrays offer more advanced features and better recoverability -
especially in situations with moving workloads around in a cloud
(VMotion or similar), host failures, SSD failures, etc.

EMC offers XtremIO


All flash array - <1ms response times (500sec)
5, 10, 20TB capacities based on 13 or 25 PCIe eMLC SSD in 400GB or
800GB
1-8 X-Bricks per rack
Can you host your entire database?? 150K 1.2M IOPS
Yes..but.might get a bit expensive 20-320TB capacity
~$25/GB*?? ~$200K/10TB*??
But then it may save on power and cooling. *anecdotal pricing for single X-Brick based
on internet chatter
.and the faster speed may have business benefits
2016 SAP SE or an SAP affiliate company. All rights reserved. Public 36
A 1TB test using EMC XtremIO

1TB Test Scenario:


HDD 83,650.52
90,000.00
1 TB data on HDD, 0.5 TB log on HDD
80,000.00
NV Cache
1 TB data on HDD, 0.5 TB log on HDD 70,000.00

~0.6 TB NV cache 60,000.00

50,000.00 37,000.00
SAP ASE database configuration per all
40,000.00 29,837.49
test scenarios:
Number of engines or threads = 48 30,000.00

Main memory cache size = 250 GB 20,000.00


4,504.00
note that main memory cache is not NV cache 10,000.00

0.00
Workload configuration: Initial TPM 1Hr Avg TPM

Number of parallel clients = 100 HDD NV Cache

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 37


Creating an NVCache

Enable MemScale Option Create an nvcache


sp_configure 'enable mem scale' ,1 sp_nvcacheconfig <cachename>,
'device=<device_name>',
Create a virtual device for the cache dirty_threshold=<threshold_percent>

Remember, this is for a cache, so create it a Delete an nvcache


bit bigger than you think you need (e.g. 1%) sp_nvcacheconfig <cachename>,
See next slide for calculations 'device=NULL',
disk init name="<cache_name>",
physname="<device_filename>", List nvcaches
size="<cache_size>", sp_nvcacheconfig <cachename>
type='nvcache' sp_nvhelpcache [<NV_cachename>]

Create nvcache (see to right) Bind database to nvcache


sp_nvbindcache <nv_cache_name>, <database_name>
Bind database to nvcache (see to right)
Only one DB per nvcache and vice versa Unbind database from nvcache
sp_nvunbindcache <database_name>

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 38


Using NVCache with Suite on ASE

Observation: Best practices recommendations are superseded for NVCache by the below
Best practices cache implementation
Separate cache for queue tables
Separate cache for system tables
Separate cache for transaction log
.the rest of the SID database is in default data cache
.however, there are large IO pools in all the named caches

Suite on ASE with NVCache


Eliminate queue, system and transaction log caches (give back to default data cache)
Bind SID database to NVCache
Remove large IO pools from default data cache

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 39


Future Development
.that could impact Suite on ASE

Public
ASE DRC/MVCC Architecture planned for sp03 (mid 2017) Future

SQL Queries & DML on Hot Data


In-Memory Row Store
Data Row Cache (DRC)
Design Considerations Latch-free B-tree indexes
MVCC Data Row Caching MVCC
Backward compatibility Dump/Load DB Persistent store
Tight integration with existing data / tables / Dump/Load Tran Uncompress w/ row
architecture optimized access
Granularity of caching Initially per-table, Backup
eventually per-partition DRC. Tailored for ILM
Application Changes Target is to keep
them minimal, simple, to none Replication
Memory Requirements On-demand. Sub- Pack
set of table / partitioned can be cached Commit time
Heat
Persistence
Dynamic Target is to allow caching to be Delta log
dynamically enabled / disabled Normal page-based
Encryption, HA, Replication Goal is to buffer cache
fully support other features in ecosystem Compressed or uncompressed
MRULRU (strict) or relaxed
Monitoring, Advisory, Wizards Intelligent
tooling & monitoring provided to optimally size
memory storage for current work loads On-Disk Row Paged I/O Txn Log
Store Log (ODRS)

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 41


In-memory row store & SAP Business Suite Future

Currently IMRS supports


Fully caching an entire table
Caching a single partition
Could be automated using existing Dynamic Storage
& Access Management (DSAM) capabilities

Implementing in Business Suite


Needs to be investigated & timing determined by
porting team
Fully caching queue tables could be beneficial
Caching current data from key transaction tables (e.g.
VBAK) may help, but would require partitioning
BW does partitioning, but for ERP, currently tables are
not partitioned
Partitioning in OLTP needs careful consideration due
to impact on indexes, query performance, etc.
However, it could also benefit ATM, so

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 42


MVCC Future

Currently Suite on ASE doesnt use locking optimizations


Readpast locking not used (would avoid dirty reads)
Uncommitted insert by-pass/pseudo column locking disabled (due to SAP logic on failed updates)

Result is it uses 2 connections for each WP


This is the same for any DBMS that use locking for concurrency control
One connection is used for all dirty reads
These can have some interesting impacts on query execution/DDL commands

ASE 16 sp03 will have MVCC


Suite porting team will need to determine adoption timing - most likely considerable time after GA

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 43


Summary

Full database encryption


Use it if needed, but implement after migration and consider increasing cache (or use NVCache)

Index compression
Implement on an as-needed basis only on large indexes that arent used much

MemScale Features
SNAP/Compiled Queries is definitely usable
Latch-free B-trees may only be needed on work flow queue tables or key transaction tables
Lockless Buffer Manager - could be useful if not a lot of cache volatility
NV Cache - most likely usable when lockless buffer manager isnt

Future plans
In memory row store - speed up queries on work flow queue tables.
May also benefit key transaction tables if partitioned (TBD)
MVCC may eliminate overhead of extra connections/dirty reads
2016 SAP SE or an SAP affiliate company. All rights reserved. Public 44
SAP TechEd Online

Continue your SAP TechEd


education after the event!
Access replays of
Keynotes
Demo Jam
SAP TechEd live interviews
Select lecture sessions
Hands-on sessions

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 45


Further information

Related SAP TechEd sessions:


DMM204 - SAP Business Suite on SAP ASE: Find and Fix Common Query Performance Issues
DMM809 - Road Map Q&A: SAP Adaptive Server Enterprise (SAP ASE)
DMM263 - Install, Deploy, and Use SAP ASE on SAP HANA Cloud Platform (Hands on)***
DMM211 - Incorporating SAP HANA into an SAP ASE OLTP Reporting Environment

SAP Public Web


http://scn.sap.com/community/ase
http://scn.sap.com/community/ase-custom-applications
www.sap.com

SAP Education and Certification Opportunities


http://help.sap.com/ase1602
www.sap.com/education

Watch SAP TechEd Online


www.sapteched.com/online

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 46


Feedback
Contact information:
Please complete your
Jeff Tallman
session evaluation for Product Expert
jeff.tallman@sap.com
DMM214.

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 47


2016 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate
company) in Germany and other countries. Please see http://www.sap.com/corporate-en/about/legal/copyright/index.html for additional trademark information and notices.

Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.

National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its
affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and
services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as
constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop
or release any functionality mentioned therein. This document, or any related presentation, and SAP SEs or its affiliated companies strategy and possible future
developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time
for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-
looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place
undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.

2016 SAP SE or an SAP affiliate company. All rights reserved. Public 48