The only database with bidirectional compatibility towards Oracle DB & Exadata
Engineering with DELL EMC Technologies + Tibero DatabaseTogether with DELL EMC, we have engineered an open platform that is directly compatible with current PL/SQL-based applications and it covers Oracle Exadata main functionalities to speed up your production databases, provide flexibility and eliminate vendor lock-in.
Instead of migrating or facing a heavy transformation.
It is just a data transfer process.
Table Of Contents
- Introduction
- The only solution with bidirectional compatibility
- DELL EMC Architecture
- Why an Open Platform?
- Why Tibero Database?
- Possibilities
Introduction
The necessity of writing this post comes after the request of several companies in the area of insurance, financial and public sector to have an alternative to Oracle Exadata that allows them more flexibility.
In this article we will explain why Tibero is the only database that has bidirectional compatibility to Oracle Exadata.
Each company have a different target, for example:
- Company A wants to get rid of Exadata because they are no longer comfortable with Oracle Corportation due to pricing, sales aggresiveness and high hardware maintenance costs.
- Company B would like to go the Cloud (meaning any of the main 3 Cloud providers; AWS, GCP and Azure) but they feel forced to go the Oracle Cloud which in their point of view, it is not comparable and they do not want to create a lock-in dependency with ExaCC service.
- Company C desires to have a hybrid-cloud solution but also want to set a standard hardware for on-prem that it is scalable and compatible for most DB Engines they have in operation.
Tibero Database can meet the requirements of all these 3 companies at the same time.
Tibero can be used with any hardware and any cloud. In this post we will focus on the benefits of using Tibero with DELL EMC mainly.
At the end of the article, you will discover interesting combinations as for example, combining this solution with VMWare vCloud enables customers to have a hybrid solution that is very portable.
The only solution with bidirectional compatibility
Bidirectional compatibility: You are able to move a database from Oracle Exadata to Tibero without changes in most cases and this same Tibero database can be moved back to Exadata if required.
Preserving important features like Smart Scan (Predicate Filtering in Tibero) and Columnar compression, sharing the same syntax and table definitions.
Providing portability and flexibility to customers.
DELL EMC Architecture
Compute Node (2) |
Storage Node (3) |
| AMD EPYC 7742 64-Core Processor 2250 MHz | AMD EPYC 7402P 24-Core Processor 2800 MHz |
| 512 GB RAM | 256 GB RAM |
| 4×1.2 TB SSDs for OS | 8×3.2 TB Dell Express Flash NVMe P4610 3.2TB SFF => Download Datasheet |
Why an Open Platform?
“A hardware that can be replaced by other vendor, a hardware that can be used with any other software.”
The use of Tibero is not restricted to DELL but Tibero can be used with any hardware vendor.
At the same time, the hardware from DELL, as any other vendor, it is modular and it counts with different quality tiers that can be combined to match customer budget and level of service targeted.
Why Tibero Database?
Tibero database is the only database with Exadata-like features. Concretely but not the only, as follows:
| Oracle Exadata | Tibero Database |
| Smart Scan (the main “secret sauce”) | Predicate Filtering (Storage Processing) |
| Hybrid Columnar Compression | Tibero Columnar Compression |
It also provides the highest compatibility level to Oracle Database in terms of PL/SQL support. Meaning that 80-90% of in-house applications can be just transferred instead of migrated. The application will share same PL/SQL code, table data types and structure.
As well, in the next section, we will discuss possibilities that increase the interest on Tibero Database as Exadata replacement or coexistance.
The direction of Tibero regarding licensing and their way of treating customers is much more friendly for us and for our customers.
As for example, all available features in Tibero are included by default and we do not need to take care of compliance and developers are free to use whatever they need to build a good application with a powerful backend.
Examples of Compatibility
As an example, a partitioned table can be created in Tibero database using the same syntax as in Oracle Database (or Exadata).
CREATE TABLE PART_TABLE_TEST
( COL1 NUMBER NOT NULL,
COL2 NUMBER NOT NULL,
COL3 NUMBER NOT NULL)
TABLESPACE USERS
PARTITION BY RANGE (COL1)
( PARTITION PART_TABLE_TEST_P1 VALUES LESS THAN (20150201) TABLESPACE USERS,
PARTITION PART_TABLE_TEST_P2 VALUES LESS THAN (20150301) TABLESPACE USERS,
PARTITION PART_TABLE_TEST_P3 VALUES LESS THAN (20150401) TABLESPACE USERS);
Columnar Compression
ALTER TABLE PART_TABLE_TEST MOVE PARTITION PART_TABLE_TEST_P1 COMPRESS FOR ARCHIVE HIGH TABLESPACE USERS;
TCC or Tibero Columnar Compression is available in the following forms:
- COMPRESS FOR QUERY LOW.
- COMPRESS FOR QUERY HIGH.
- COMPRESS FOR ARCHIVE LOW.
- COMPRESS FOR ARCHIVE HIGH.
From QUERY LOW to ARCHIVE HIGH, you have different levels of compression and performance. QUERY LOW is the best for OLTP Tasks and ARCHIVE HIGH is the best for cold not-often-updated data.
Aditionally, for tables you want to use for OLTP and also have some level of compression, you can simply use COMPRESS keyword. This is similar to “COMPRESS FOR OLTP” in Oracle.
Difference
In Oracle Exadata (19.4 APR2019) you cannot compress a table with bitmap indexes. You should drop them first and it will impact your production performance during the time these bitmap indexes are not available.
This is a customer real-world example and it impacted in 3 maintenance weekends at customer side to compress certain tables in the customer Enterprise DWH. Public sector.
In Tibero (v.6 FS7 2018), you can do this operation online and without affecting the operation.
Oracle would always say that this is a bug and version dependant error but in our experience working with Tibero since 2017, we have found other functionalities that were not working as expected in Oracle but we have not found this in Tibero DB.
Predicate Filtering (Storage Processing)
If you want to read about this functionality, you can review this short post.
To summarize, Predicate Filtering is the ability to pre-process the WHERE clause of a data access (e.g. SELECT) at storage level.
This behaviour reduces the amount of data that has to be transferred+parsed at network and RAM memory level.
Predicate Filtering is very critical when dealing with large volumes of data (e.g. over 100 TB) but you can feel the difference as well on a database under 100 GB.
Predicate Filtering functionality can speed up data access on an average of 20 times.
Without Predicate Filtering
Databases using this method:
- Oracle Enterprise Edition
- PostgreSQL
- MariaDB
- etc
* While no indexes present. (FULL SCAN)
With Predicate Filtering
Databases using this method:
- Tibero Database
- Oracle Exadata
- IBM Netezza (Manual config required)
- ?
* While no indexes present. (STORAGE SCAN)
Possibilities
- Able to replace Oracle Exadata with similar or better performance.
- Able to use same DELL EMC Hardware for most kind of databases, not only Tibero Database.
- Able to coexist and port databases with Oracle Exadata.
- Able to mount a hybrid Cloud using Cloud native services and independent hardware On-Prem.
- Able to combine with VMWare vCloud for Private or Hybrid Cloud architecture
- Able to use Containers
- Able to use all functionaties with Tibero Database to develop a very sophisticated backend.
(Tibero licensing model comes with all included by default)
