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)
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);
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.
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
* 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)
- 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)