Depending on point of view, ALTIBASE architecture is similar to ORACLE except two major differences.
- ALTIBASE does not only support DRDB (Disk Relational DB) but MRDB(Memory Relational DB).
- ALTIBASE is 1 process, multithreaded architecture while Oracle is multiprocess architecture.
We'll discuss about the architecture difference between the two DBMS's.
Comparing architecture with ORACLE
Here's summation of ORACLE Database architecture.
ORACLE instance does consist of the following constituents.
- SGA (Shared Global Area)
SGA is a shared memory used by ORACLE Processes. SGA consist of data buffer cache, shared pool, redo log buffers and so on. This component corresponds to the Disk Buffer in ALTIBASE HDB.
- ORACLE Processes
ORACLE Processes are for executing queries which user sent, or maintaining ORACLE instance. In constrast to ORACLE, ALTIBASE HDB
Files are used by ORACLE Proess.
ALTIBASE HDB Architecture
Here's briefing of ALTIBASE HDB architecture.
ALTIBASE, in contrast to ORACLE, is a single process with multithreads and can handle both in-memory data and disk data using intergrated query processor.
Therefore, ALTIBASE HDB does not require big shared memory segments such as SGA.
Memory segements that ALTIBASE HDB use consists of
- Memory Tablespace
Because ALTIBASE supports in-memory database facility, user can create tablespaces in main memory. ALTIBASE HDB supports four types of memory tablespaces.
SYS_TBS_MEM_DIC is a tablespace which stores ALTIBASE HDB meta information in memory.
All meta information are stored in memory.
It is almost same with Library Cache in ORACLE.
Besides ORACLE stores its meta data in disk but ALTIBSE HDB stores its meta data in memory.
This tablespace can not be dropped.
SYS_TBS_MEM_DATA is a default memory tablespace.
You can specify its size when you create database.
This tablespace can not be dropped.
User Memory Tablespace
User memory tablespace is a kind of tablespace which resides in memory.
You can create or drop user memory tablespaces in service time if there is no transaction which access the tablespace.
You can specify its size when tablespace creation time.
Volatile User Memory Tablespace
This tablespace does not issue any I/O.
It is useful when you want to store temporary data.
Because there is no transaction logging and no checkpoint issued in volatile tablespace, all data is automatically deleted after restarting ALTIBASE HDB.
(But Object schema, such as table and synonym, are not deleted becuase object schemas are stored in SYS_TBS_MEM_DIC tablespace.
- SQL PLAN Cache
SQL PLAN cache is similar facility like Oracle Library cache in Shared pool.
To reduce I/O contentions while accessing disk data, ALTIBASE HDB creates Buffer Pool to cache for read or written data. It is almost same as Buffer Cache in ORACLE.
and ALTIBASE HDB has its own threads to execute query that user request or to maintain ALTIBASE HDB properly.
- ALTIBASE thread list.
Executes query that user sent and returns result.
Monitors socket that client attempts to connect to and hands over client session to Service Thread.
Check whether the client session is connected or not.
if disconnected, Session manager cleans up the resources that belong to the disconnected session.
Load Balancing Thread
This thread is responsible for well-spread workload.
If one service thread is busy, Load balance thread steals a task from the busy thread and rearranges the task.
If all service threads are busy, it creates a new service thread.
Log flusher thread
This thread is responsible for log flush.
Service thread writes its transaction log into log buffer (which resides in Kernel or User space).
Log flusher thread flushes its transaction log from buffer to disk to ensure durability.
Any changes in Disk tablespaces are written in Disk Buffer Pool first.
and then Flusher thread writes dirty pages (the changed pages) from Disk Buffer Pool to data file.
It is almost same with DBWR process in ORACLE.
Log file manager thread
This thread is responsible for preparing and creating log files.
Because of WAL (Write Ahread Logging) protocol, all changes should be logged before changes.
To avoid the contentions between writing and creating log files, this thread creates and prepares logfiles.
Logical Ager thread
This thread is responsible for index garbage collection in memory tablespaces.
This thread releases and cleans up unused index memory to be reused.
This thread is responsible for data garbage collection in memory tablespaces.
This thread releases and cleans up unused data memory to be reused.
It is not same the meaning of ALTIBASE HDB checkpoint with ORACLE checkpoint
because ALTIBASE HDB checkpoint thread is responsible for not only Disk Buffer checkpoint but also memory checkpoint.
Checkpoint thread flushes all dirty pages in memory tablespaces and synchronizes memory checkpoint image to memory tablespace
and then it deletes all unnecessary log files.
This thread is responsible for archiving log.
This thread is activated only in archive mode.
Archived log is necessary for online backup and recovery for media failure.
Replication Sender thread
This thread is responsible for sending xlog to another ALTIBASE HDB which reside in another machine (or same machine).
This thread reads transaction log and translates logfile to xlog to provide HA(High Availability) feature.
Replication Receiver thread
This thread is responsible for receiving xlog which another ALTIBASE HDB Replication Sender sent, and apply the xlog to its DB.
Database configuration file.
This file is read by ALTIBASE server when ALTIBASE HDB starts up.
It is same with ORACLE PFILE (parameter file).
The location of this file is $ALTIBASE_HOME/conf/altibase.properties
Log anchor file
Log anchor file is a small binary file that stores physical information of database including tablespace, data file, SCN (System Change Number) information and so on.
ALTIBASE HDB has three log anchor files as Oracle has three control files because these files are very important.
It is almost same with Control file in ORACLE.
You can dump and analyze this file using dumpla command.
Memory checkpoint image
Memory checkpoint image is files in disk, which is identical copies of memory tablespaces in ALTIBASE HDB.
During checkpoint phase, ALTIBASE synchronizes the data of memory tablespace to memory checkpoint image in disk.
A memory tablespace needs two memory checkpoint images because ALTIBASE HDB uses ping-pong checkpoint mechanism to reduce I/O and lock contention.
This file is for storing disk tablespace data as ORACLE does.
It is exactly same with ORACLE data file.
A tablespace consists of datafiles.
Transaction Log file
This file is for storing transaction log to ensure durability of ALTIBASE HDB.
According to WAL (Write Aread Logging), All changing transactions have to record their change logs in Transaction log file before change regardless tablespace type.
(Memory tablespace or Disk tablespace)
Archive log files is for media-failure recovery.
They are identical to transaction log files but these files are not removed automatically.
DBA (Database Administrator) is responsible for managing archive log files manually according to backup policy.
Password file is for storing the password of SYS user (super user)
Double-write buffer file
Double-write buffer file is for saving temporarily saved disk pages.
Comparing Storage structure to Oracle
ALTIBASE is hybrid database management system. That is, ALTIBASE provides both in-memory database feature and disk database feature. So it would be difficult to compare ALTIBASE HDB to Oracle simply.
DRDB (Disk Resident Database) Structure
In fact, ALTIBASE DRDB is almost same with Oracle storage structure.
Here're explanation about elements of storage structure.
A page the minimum unit of database I/O. ALTIBASE HDB / ORACLE manages its data using page structure.
Here're the features which ALTIBASE HDB does not support.
Changable page/block size
The page size of ALTIBASE can not be changed.
ALTIBASE does not support page compression.
Except above features, ALTIBASE data page is almost simllar to ORACLE's including PCTFREE / PCTUSED storage parameter.
An extent is a logical unit of database storage space allocation made up of contiguous data pages
A segment is a set of extents that contains all the data for a logical storage structure within a tablespace
A tablespace is a logical storage container for segments.
In-memory DB stucture
Although ORACLE does not support in-memory database feature, it is important to understand ALTIBASE memory db structure
in order to maximize ALTIBASE HDB utilization before migrating from ORACLE.
Here's a structure.
All table's meta information is stored in Dictionary Tablespace (SYS_TBS_MEM_DIC),
and table header, in the dictionary tablespace, points the location of first memory page.
Page is the smallest unit of I/O. Its size is 32KB.
In in-memory db, in constrast to DRDB, it doesn't matter whether pages are allocated physically contigous or not because it costs little for random access in memory. An Extent is just a container of memory pages. Default memory extent size is 256KB, It means a extent has 8 pages. If there is no available extent in the table list, a service thread request a extent to the tablespace.
- Free Page
A list that contains free pages of memory tablespace. If free pages are exhausted, ALTIBASE automatically requests memory chunk from OS it reaches MAXSIZE.
A container where memory indices resides. A index does consist of only ordered-pointers, which points the record address in page, and it does not contain the column value. Moreover index is not persistent, that means that the memory index in ALTIBASE does not issue any logging when index structure is modified. Because of this feature, ALTIBASE always rebuild its memory indices at startup. Here's a brief comparison between memory index and DRDB index.
ordered-pointers which point physical memory address
column value and row logical address that contains the column
logging at every changes