Relational Databases Forum

Ariel Lindenfeld
Sr. Director of Community
IT Central Station
Sep 24 2018
Let the community know what you think. Share your opinions now!
it_user182115Backup and replication options.
Rhea Rapps
Content Specialist
IT Central Station
Jul 28 2018
One of the most popular comparisons on IT Central Station is SAP HANA vs SQL Server. One user says about SAP HANA, "[It] provides us with predictive capabilities for asset maintenance and real-time forecasts." Another user says about SQL Server, "While it didn’t have all the abilities of a true data warehouse, it was quickly implemented and well served for the desired purpose."In your experience, which is better and why?
Bruce GreeffThe two are not really directly comparable. HANA DB is designed to run in-memory. It indexes every attribute and converts values to integer, offering real time performance. SQL Server is a more general purpose, inherently relational product. Depending on use case - either may be better. HANA is entirely next generation. SQL Server has to maintain legacy compatibility - but it is easier to use and you can scale the infrastructure cost down. HANA is designed for appliance deployment. Scaling is expensive. To get similar capabilities to HANA you might have to add something like SPARK and /or REDIS to your SQL Server. Then it starts getting expensive and complex too.
Evan HaxtonA lot depends upon what application is running on top of the data store. If you are running SAP Business One, a compelling argument is made here . Essentially, SAP HANA (SAPH) offers in-memory processing and should be faster in most cases. However, if you are running SQL Server, you will have to access the data first before it is cached into memory. If you are a smaller organization it shouldn't matter what repository you are using. However, larger organizations may be more interested in SAPH for in-memory and analytics capabilities. For generalized use, you will more interested in SQL Server simply for the availability of API and third-party tools. See here
JanisGriffinI think I would prefer SQL Server over HANA because it's been around longer and is more well known. Also, the later versions of SQL Server allow for in memory column store, faster analytical queries and plays well with open source solutions.
Rhea Rapps
Content Specialist
IT Central Station
Apr 11 2018
One of the most popular comparisons on IT Central Station is IBM DB2 vs Oracle Database. What is the biggest difference between these two solutions? Which would you recommend? Thanks for your help! --Rhea
Rehana ParvinI think -- Oracle is well known for its performance and security feature and continuous efforts to reach the highest level of performance. A few comparisons are given below: 1. Oracle has multi version read consistency -- but not in DB2 2. In oracle, neither read nor write blocks each other-- DB2 -read blocks write and write blocks read 3. No Dead locks under load in Oracle whereas deadlock is a serious problem in DB2 4. In Oracle --intelligent advisories such as SQL Tuning, Index, Summary, MTTR but in DB2 only Index advisory presents. In terms of Self-tuning capabilities-- Oracle has Automatic Performance Diagnosis, Automatic SQL Tuning , Self-tuning memory, free space, and I/O management and so on but in DB2 No equivalent or limited capabilities Besides all good features exist in Oracle but it is bit complex. When problem occurs then figuring out the right problem in a very short time has become a challenge, Also Oracle is bit expensive. There are a lot more difference. I think you can find good resource by searching online. I think all database software has their own advantages and disadvantages. Depending on the budget and compromises in which feature loss they can afford--companies decide their choices.
Martin Spratt (2300+ Connections)Both DB2 and Oracle are legacy relational databases. 20+ years ago you might pick DB2 for reliability and scalability, but today you would choose Oracle for the sheer size of partners, applications, skills and tools available. So if you have to pick today, I would choose Oracle (I am an ex IBM DB2 Lab person and used to be VERY DB2 bias as it's an excellent engine)... and if I ask you more detailed application and business landscape questions I would recommend decommissioning BOTH those legacy databases and move to PostgreSQL, MariaDB or MySQL (MySQL is ironically now owned by Oracle too), and cloud host your database farm. If you had to pick a legacy "perpetual license" relational database I would go wall to wall MS SQLServer. That's what I would generally recommend without knowing more about your application or business landscape. (SAP, Apps, Mobility, Cloud, Regulatory, Security, HA, Scale, etc etc).
Leonidas GiannoulisWe use both databases (and some more), I would definitely suggest using Oracle against DB2 for better performance but also because it's easier to find collaboration tools and find help. PS : My preference is MS SQL.
AmitBajaj
Head - Server and Storage at a financial services firm with 1,001-5,000 employees
Does running Oracle 11g and 12c databases under OLTP type workload on SPARC architecture really offer performance benefits compared to a similar specification Intel based server (keeping the Core-count same to remove the licensing from the picture)?
Bobin VargheseIn my experience SPARC provides far better performance than x86 based server. Databases are more responsive and way quicker to start. Recently, I had the privilege to run 70(Yes, 70) databases on a single E25k SPARC server with around 256GB RAM. No issues whatsoever. Try running half of that on a x86 based server and it would be a disaster. Having said that, I am sure you must have read that Oracle has stopped further development of SPARC which indirectly means that it will stop SPARC sooner rather than later. Would you still want to use/move to SPARC servers?
Miguel A AlvarezHi, The answer for your question is a simple: yes, it performs better on the same configuration memory/cores. The reason is simple: sparc performs much better than intel, and the architecture designed by oracle to get the most of their processors it is really good. Besides, using red hat as a SO, on intel processors, the gap is shorter. But the winner is SPARC.
Lavanya Anbalagan
Project Manager - HCM Solutions at a tech vendor with 1,001-5,000 employees
Looking for a comparison of Microsoft SQL 2017 and SAP Hana.
Mordechai DanielovSAP Hana under the full use license can support non-SAP applications that's not the problem, but I don't think anyone would want to do it because of its high cost. Also notice that SAP HANA uses it's own SQL flavor and has a limited choice of drivers.
Sangeetha RamamurthyThere are several similarities b/w the relational databases. I would go with one or the other only based on the use-case. This particular tabular format helps compare and contrast the features. https://db-engines.com/en/system/Microsoft+SQL+Server%3BSAP+HANA
Royden AkerleyDP DHL does use both tools but the use is largely restricted by business function. To begin with I must set the context of which we use these tools. I need to point out we also use Software AG's Terracotta and Mongo db for in-memory solutions as well as SAP's Hana. Terracotta is used for persistent memory associated with our ESB and Complex Event Processing, while Mongo db is primarily for report and user facing applications. Hana is largely confined to within the Global Business Management with limited use outside that division. All in-memory solutions are considered secondary drawing their data from relational data stores which is usually denormalized to support rapid access. MS SQL is used for departmental level data stores and usually for non-mission critical applications. We have as primary data stores Oracle, Informix and Teradata (for data warehousing). MS SQL is usually defined as a functional data store (not really an ODS) and rarely connected to on-line transactional processing, but frequently as a localized data mart or in a supporting function. The difference we have experienced between the tools was on speed of resolution for on-line requests, and if atomic, relational data was needed. Hana worked well for us in areas where using large volumes of aggregated and unstructured data for analysis. It was primarily tied to our SAP ERP solutions with the native integration a prime feature. We rarely found it useful in big data search as we tend to approach big data in a non-standard and proprietary approach. Hana allowed close integration s well to a number of statistical modeling tools that support the financial analysis and forecasting. MS SQL excelled in the areas of data quality validations, drill down of finite sets of data for a given subject area (limited business objects over small temporal windows). It integrated well and was actually a necessity for the use of the Microsoft BI stack, and tools. These are usually locally enabled, along with Tableau and Qlik-View by business functions. However, once “productionizing” the analytics we move to in-house developed solutions to reduce license and run costs. Each tool has its own niche within DP DHL, and there is no view to replacing one with the other.

Sign Up with Email