cancel
Showing results for 
Search instead for 
Did you mean: 

SAP ASE future after S/4 HANA?

Former Member
0 Kudos

Hi

Just want to start discussion about the SAP roadmap.

SAP business suite maintenance will be end at 2025, on that time i assume that most of SAP user will be on / already move to S/4 HANA. Almost all SAP application now available on HANA, even solution manager running on HANA. So after 2025, what is the SAP ASE role in SAP landscape? Because SAP always push all their product towards HANA database, it seems like no place for old type database (the database that still save their active data on hard drive) anymore in SAP roadmap, even for their own product SAP ASE.

Correct me if i'm wrong.

regards

Andreas A Krisnadi

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member

Good question Andreas.

Not very much sure about the future of SAP ASE. or where is it heading to. This has been a concern for me as well , like you.

Regards,
Ajith Prabhakaran

former_member89972
Active Contributor
0 Kudos

This is a perspective from me as end user of SAP ASE/RS/IQ and of late some exposure to HANA.

We all can agree on the fact that most organization that have OLTP also need fast reporting + analytics.

User expectation also grow from batch processing (some delay) to online (delays in minute(s))  to near real time (milliseconds ).

ASE (properly tuned) is very good at OLTP.

It is also good at Qurery reporting if so tuned (indexes, caches, in memory tempdbs etc).

.

So SAP/Sybase seems to have following possible solutions for OLTP + DSS requirements.

1. ASE (primary for OLTP)  + ASE ( 1 or more copies replicated and tuned for DSS/Reporting)

   This could be WS, MSA, one way replication etc.

    Both are same flavor of ASE so T-SQL code can work on either.

    So at minimum  needs two DB servers and a RepServer

2. ASE (primary for OLTP)  + IQ for reporting (replication from ASE to IQ)

    IQ has slightly different  flavor of SQL so some code tweaking is needed.

    At mimimum needs two flavors of DB servers and one RepServer

3. HANA (where OLTP + DSS/ANALYTICS/REPORTING) are merged in one server

    with many more features and excellent performance for both OLTP and Reporting

    Needs one (expensive ? ) database server + different flavor of SQL

    So some changes needed to port existing logic. New development is not an issue.

With the above in mind,  to me,  it seems to be a writing on the wall that HANA will prevail, especially as h/w prices fall and after SAP recovers substantial part of their initial development cost.


Companies ( for short term valid business reasons ) may decide to stick to what is working and choose not to upgrade/change.   Long term they will have to make choices

BTW :  ASE is used for bespoke custom applications too.  So this discussion of ASE's future is of interest from that angle too.

Avinash

former_member182259
Contributor
0 Kudos

The problem is that OLTP query optimization and Analytics query optimization are decidedly two different animals - much like OLTP storage (row) vs. Analytics (column) are different.   For example for OLTP queries, the optimizer has to look at which index is the best for the joins across the known/usable SARGS for each set of predicates (set defined as bounded by disjoint sets such as OR clauses).  The resulting rows are unioned (if necessary).  Unless specified, it is most advantages for OLTP engines to look at it from a single threaded point of view due to high user concurrency and desire for low latency queries in OLTP.   The expectation is that the ratio of rows scanned vs. materialized is actually quite small - primarily based on the premise that rows scanned ought to be proportionately small.....(the entire theory of index selectivity is based on that from a optimization costing aspect).  It is also based on the fact with OLTP the access methods are usually fairly well established - e.g. you could just about picture an application API with very little adhoc requirements.  Net is that query optimization time needs to be minimized as query execution ought to be blistering quick.   That doesn't mean there are no reports - e.g. check order status, weekly/monthly/quarterly canned reports are required....but definitely not the drill-down multi--dimensional analysis type queries.

For analytics, it usually involves which is the best way to access each column - e.g. almost a best index/access method per column - and then to parallelize the query across as many cores as possible.  The rationale is that rows scanned is likely going to be extremely high.  Consequently, then the column intersection is used to determine the projection (vs. the row union).   With the large volumes of data scanned/materialized, the query optimization time becomes key - e.g. it is better to run the optimization longer if it yields a lower cost plan or faster plan as execution time will be the bulk.   It is also expected to have a very large adhoc requirement and less structured access methods.

With differences in query optimization/execution as well as storage, one starts to wonder about the wisdom of trying to do it all in one DBMS engine.   Is it doable???   Absolutely!!!   But what is the cost to the OLTP side to have the extra code paths to navigate - even the extra code path is a single instruction to bypass the DSS code path.....and given the data needs two different structures, do we duplicate the data...or make one an in-memory structure that is populated at runtime (which is a bit of a slow process as well).   Given that case, the question is why not have separate engines with an easier data movement/transport between them - which is where ASE is focusing - HANA SQL support (coming) allowing common application development.   We need to get SRS to be much easier to use as well as sustain the transfer volume as well (along with the enhancements to ASE).

Former Member
0 Kudos

> The problem is that OLTP query optimization and Analytics query optimization are decidedly two different animals


Whilst that is true - I've only ever worked on environments that do both.

And here no one wants 2 db servers, on 2 machines with 2 different dialects of SQL.


At least if IQ, ASE and HANA shared the same dialiect we might ever think about having both.

(although IQ and ASE are pretty close and 90% of all code will port easily)


former_member89972
Active Contributor
0 Kudos

SAP having three (or possibly more ?) SQL flavors to support databases is of course direct result of acquisitions.  ASE, IQ and HANA representing three different starting points.

To Sybase's credit they realized the need to have one SQL flavor very quickly and made the two flavors in ASE and IQ almost compatible.

Hopefully SAP now will make efforts to standardize and enhance the new dialect.

I have seen ASE warm stand by, MSA and in few cases stand alone report servers (ASE/IQ) leaving OLTP on a separate server.

And need for HANA type of single database solution is borne out of not having to maintain different servers and efforts to keep the data in sync.

We have initiated process to look at "HANA Accelerator for ASE" to leverage existing logic built to use the ASE and eventually may start developing new Apps for HANA.

Cheers

Avinash

Former Member
0 Kudos
  • To Sybase's credit they realized the need to have one SQL flavor very quickly and made the two flavors in ASE and IQ almost compatible.

Yes - but when they bought IQ they could have put ASE SQL on it rather than ASA. I did a POC port to IQ 10 years ago and as far as I'm aware no changes have been made to iron out the last few differences in SQL

  • Hopefully SAP now will make efforts to standardize and enhance the new dialect.

The last conversation I had with SAP was that there were no plans to made their products use the same SQL version. Perhaps this has changed ?

  • I have seen ASE warm stand by, MSA and in few cases stand alone report servers (ASE/IQ) leaving OLTP on a separate server

Yep - we've looked at doing the same thing and ran a POC. Decided against it due the extra infrastructure and complexity.

former_member182259
Contributor
0 Kudos

We have had a number of ISUG sponsored events here in the US to precisely explain this. 

*** CAVEAT ***   The below represents a condensed summary of current planning from SAP and may change at any time.

1) First of all, while SAP expects most customers to move to S4/HANA, they know some customers won't and will remain on R3/ANYDB.  So, for the forseeable future (at least through 2025 as of now), the intent is that ASE will continue to support Business Suite on ASE applications.  This will involve in the near term adding SAP Core Data Services functionality such as C-language UDF, Intersect/Minus SQL primitives and other enhancements that non-SAP application developers can use as well.

2) XOLTP - particularly high concurrency XOLTP (vs. low concurrency streaming environments).   While one could say the focus of 15.7 was on #1, the focus of 16.x has shifted more towards OLTP/XOLTP.   This is evident in ASE 16sp02 and will continue with ASE 16sp03 with enhancements around in-memory (w/ persistence) techniques that will allow lower latency queries.  Unlike the only other competitor looking at XOLTP, however, our intent is to avoid having to do entire rewrites of the application.   Note however, that unlike the focus of most competitive COTS DBMS's, the focus for in-memory will be on XOLTP and not Analytics (given HANA, why would we do that?)

3) Integration with HANA - this will include support for non-columnar HANA SQL schema/script support allowing developers to develop apps for SAP DBMS's in a common language and deploy the apps appropriately for XOLTP or Analytics.  We also want to make it much easier for OLTP/XOLTP apps to have near/real time data movement to HANA

Other areas we are looking at/involved in already include cloud enablement functionality (hence the shift in focus away from hardware dependent HA solutions such as OS clusters and Shared Disk Clusters with implementations such as Always-On).   There are other topics we are looking into, but one might simply remember that the central focus moving forward will be heavily around OLTP/XOLTP.

For more details about the plans/efforts, I would suggest attending either the ASE Preconference at TechEd or one of the upcoming TechSelects (one in NY on Oct 13 and one in London on Oct 19).  Depending on interest, there may be additional ones in other areas.