Document Information

Issued Date: 2025-03-31 Software Version: Zetadata v.7.2.3 Document Version: v1.0.0

This guide is intended for database administrators who install and operate Tibero ZetaData (hereafter ZetaData).

Required Knowledge

• Database

• RDBMS

• Tibero

• Operating systems and system environments

• UNIX and Linux

This copyright notice applies to the TmaxTibero ZetaData manual.

45, Jeongjail-ro, Bundang-gu, Seongnam-si, Gyeonggi-do, Republic of Korea

Tel : +82-1544-8629

E-Mail : gitbook@tibero.com

The contents of this software (ZetaData) manual and the program are protected by copyright laws and international convention. The contents of this manual and the programs described herein are available only under a license agreement with TmaxTibero Co., Ltd. and may be distributed or reproduced only within the scope of the license agreement.

No part of this document may be transmitted, copied, deployed, or reproduced in any form or by any means, electronic, mechanical, or optical, without the prior written consent of TmaxTibero Co., Ltd. Nothing in this software document and agreement constitutes a transfer of intellectual property rights regardless of whether or not such rights are registered) or any rights to TmaxTibero trademarks, logos, or any other brand features.

This document is for information purposes only. The company assumes no direct or indirect responsibilities for the contents of this document, and does not guarantee that the information contained in this document satisfies certain legal or commercial conditions. The information contained in this document is subject to change without prior notice due to product upgrades or updates. The company assumes no liability for any errors in this document.

TiberoZetaData is a registered trademark of TmaxData Co., Ltd. Other products, titles or services may be registered trademarks of their respective companies.

Some modules or files of this product are subject to the terms of the following licenses:

• OpenSSL

• RSA Data Security, Inc.,

• Apache Foundation

• Jean-loup Gailly and Mark Adler

Detailed Information related to the license can be found in the following directory:

${INSTALL_PATH}/license/oss_li censes

The guide contains 9 chapters.

Overview

In Tibero Active Cluster (TAC) configurations that do not use storage nodes, the bandwidth limitations of the SAN switches become a bottleneck when performing large amounts of I/O. To solve this problem, ZetaData uses high-bandwidth InfiniBand instead of SAN switches. However, it doesn't change the fact that it needs to transfer large amounts of data over the network.

ZetaData's Function Offloading function serves to significantly reduce the amount of data transmitted over the network by offloading tasks such as raw filtering and column filtering and projection that were previously performed on TAC instances to SSVR instances.

In addition, tasks that use a lot of CPU resources, such as decompression, can also be transferred to SSVR instances to utilize the CPU resources of storage nodes, which are significantly less utilized than the CPU resources of DB nodes.

Operation

Function Offloading basically operates only when querying data through Table Full Scan.

Since this function is developed to reduce data transmission in a network, it does not operate when there is not a lot of I/O such as table queries with indexes.

To efficiently use Function Offloading, do not create indexes when storing massive data in a ZetaData configuration. If you unavoidably include indexed columns in the WHERE clause to view data, you can give the query a Full Scan hint (/+full_storage(t1)/) to avoid viewing through the index. Conversely, if you do not want to use Function Offloading, you can force it with a hint (/+no_full_storage(t1)/). Another limitation is that this feature is not available for LOB columns that are stored in separate LOB segments.

Function offloading is most effective when a lot of data can be filtered out at the WHERE clause processing stage. This is because the amount of data that needs to be sent to the TAC instance can be greatly reduced by the work of the SSVR instance.

Also, because the prefetch management is done within the SSVR instance, the I/O is more efficient compared to block requests that do not use functions. However, the SSVR instance is not responsible for the number of buffer cache overflows on the TAC instance. That is, using this function is not efficient for OLTP jobs.

The SSVR instance cannot handle tables with frequent modifications because it doesn't know about the static operations. This means that the effectiveness of this feature is minimal for OLTP operations.

Data for tables viewed through the Function Offloading feature may not be kept in the buffer cache of the TAC instance. This is because it is delivered to the TAC instance in a pre-processed form from the SSVR instance and is not delivered in blocks of data. For the same reason, the effectiveness of the feature is most noticeable when working with tables that are too large to fit all the data in the buffer cache. Conversely, you should not use the feature if the data you want to view is small enough to fit in the buffer cache, or if you expect frequent views and modifications to that data so that it is already in the buffer cache.

If ZetaData is configured with TCP, not InfiniBand, SGA must be sufficient because Function Offloading results are transferred through TCP and temporarily stored in the SGA. Because the TAC instance requests as many I/Os as the number of Grid Disks in the SSVR instance at a time, it uses much more SGA space than when the function is not used.

To configure TAC instances for SGA, refer to the Tibero's configuration.

The following describes each initialization parameter for the Function Offloading function.

다음은 Function Offloading 기능과 관련한 초기화 파라미터에 대한 설명입니다.

The following is a list of functions that support Function Offloading.

Constraint: lob cannot be an input to the TO_CHAR function.

SSVR Instance Failure

If an SSVR instance fails, the TAS instance automatically detects the status of the corresponding disk and performs I/O Fail-over. If each SSVR instance is configured with a FAILGROUP of 1:1, and the redundancy level of the disk space is NORMAL or higher, all loads performed on the DB will run normally regardless of the failure of one SSVR instance.

If a sSSVR instance recovers from a failure, then the TAS instance automatically detects the SSVR instance's status to synchronize all the disks in the SSVR instance . If it is impossible to perform a failover on a SSVR instance , then that SSVR instance can be removed from the disk space. To remove the SSVR instance, connect to the TAS instance to remove the FAILGROUP that corresponds to the storage server that is to be removed.

The following is an example of removing from a TAS disk space when the failed SSVR instance is in a FAILGROUP named FG0.

$ tbsql sys/tibero@tas0
SQL> alter diskspace DS0 drop disks in failgroup FG0 rebalance wait;

There must be enough free disk space left to store the data on all the disks you want to remove.

To add the newly configured SSVR instance, add FAILGROUP using the ALTER DISKSPACE syntax in TAS.

The following is an example of adding the grid disk of a newly configured SSVR instance to a FAILGROUP named FG0 in a disk space.

If a TAC instance fails, sessions are recovered through the Fail-over feature of Tibero Active Cluster.

For more information, refer to the "Tibero Administrator's Guide".

Overview

ZetaData consists of SSVR instance, TAS instance, and TAC instance.

SSVR instances can be configured on multiple servers and are managed by TAS instances to provide volumes to TAC instances. TAS instances are also configured as clusters to match the TAC instances. We do not provide backup capabilities for SSVR and TAS . Typical TAC backups are the same as those done using a storage-agnostic database solution.

ZetaData Backup and Recovery

There are the following three methods for ZetaData data backup and recovery.

Logical backup and recovery with tbexport

Same as a general backup method. Backed up files can be loaded with tbimport.

Physical backup and recovery with RMGR

Physically backs up files managed by a database.

If a database is configured with TAS, a database file cannot be accessed with an OS utility but can be accessed with RMGR.

RMGR supports backup when a database's storage is a local disk, SAN disk, SAN disk that uses TAS, or ZetaData. If RMGR is used, backup and recovery are performed in a database node. A user does not need to perform additional tasks for backup and recovery.

Copies TAS files saved in disk spaces to a local directory by using tbascmd to execute the cptolocal command in a command line tool of TAS. It backs up all files for Tibero operation to a local file system by using the cptolocal command while only TAS instance operates after ending a Tibero instance.

Before performing recovery, perform checkpoint to save data located only in memory to flash and disk as follows:

Before performing backup, check the file type and block size as follows:

Backup all necessary files such as control, redo, and data files as follows.

TBASCMD can be accessed through tbascmd (port number). The port number is set in LISTNER_PORT of the TAS tip file.

The following is an example of backing up the c1.ctl control file locally on a TAS instance using port 9120.

The result of executing the above command shows that a backup file and a rollback script file using the cpfromlocal command have been created.

User can back up all files managed by the DB using the cptolocal command of tbascmd and then transfer and restore them to the TAS disk space of another node.

Transfer the backup files to the local directory of the node you want to migrate to and use the cpfromlocal command to copy the backup files from the local file system to the disk space of TAS. At this time, specify the file type (file type '-t') and block size (block size '-b') that were checked while backing up as arguments. There are five types of file types: CTRL, REDO, DATA, TEMP, and ARCH.

The following is an example of copying a backup file to disk space DS0 on node #1 TAS.

Overview

TCC is a data storage method that can improve compression and reduce disk I/O.

TCC collects and stores each column of a table individually and stores them consecutively instead of the traditional method of placing columns in a row.

If columns are placed in a row like this, the same data pattern will iterate, which is very effective for compression techniques like RLE (Run-Length Encoding), LZ4 (Lempel-Ziv 4), gzip (GNU zip), and bzip2 (block zip version 2).

Benefits

• Compression rate is greatly improved. The amount of improvement varies depending on a data pattern, but a user can expect an improvement of 4:1 - 10:1 in compression rate in a general OLAP business environment.

• As the compression rate is improved, the number of I/O operations is decreased. This means that if the number of I/O operations is a cause of a performance bottleneck, then performance can be improved. Furthermore, ZetaData performs decompression in a SSVR instance, so it does not consume a DB server's resources. CPU resources on the storage nodes are usually spare.

• As data is placed by columns, unnecessary columns are not read. If the number of columns that are necessary is less than the number of all columns, then the amount of I/O operations can be greatly reduced.

The following is a list of situations where using TCC can provide benefits

As described above, if an update is made for a table configured using TCC, it will lead to performance degradation. As a result, TCC is suitable for loading large amounts of data through DPL/DPI. As well, it is suitable for storing or deleting an entire table depending on the table data's lifecycle.

TCC is recommended when a full table scan is frequently used. The uses of a full table scan can be determined by selectivity or the use of aggregation.

TCC provides a high compression rate when performing directory compression, RLE, LZ4, gzip, bzip2, and differential compression. Also, if a compression rate is mostly constant, the number of recompressions will be decreased when loading data, which improves loading speed.

TCC provides benefits when only some columns of a table are needed. Compression units that correspond to unneeded columns are not read. However, if data is stored as row-oriented, then all the columns of a row must be read regardless of the number of columns needed. This results in a relatively large number of blocks to be read.

The following describes the initialization parameters related to TCC. CC_CU_BLKCNT is a system parameter and the rest of the parameters are session parameters.

When executing a CREATE TABLE command, the following options can be used to create a TCC table

This is the level that maximizes performance losses during column compression due to OLTP-like operations.

This is a medium compression level. The performance of compression/decompression is also medium.

This is a higher compression level. The performance of compression/decompression is somewhat worse.

This is the maximum compression level. It also has the lowest compression/decompression performance.

The following is an example of using the option.

While TCC offers many benefits in comparison with the row-oriented storage structure, it also has its downsides. Improper use can result in significant damage to performance.

Use caution in the following situations.

When an update is made in a table stored using TCC, the table is decompressed and its rows become row-oriented. Furthermore, more blocks must be read than compared with reading blocks in row units. For example, when executing UPDATE SET A=1, B=2 WHERE C=3, if a table is stored in a row-oriented method, then only one block needs to be read. However, if a table is stored using TCC, then three compression units must be read.

If CC_CU_BLKCNT is large, the performance is even more damaged. Each CU will need as many block I/Os as CC_CU_BLKCNT to process a single row. Therefore, if there isn't much of a difference in compression rates, it is recommended to use an appropriate size for CC_CU_BLKCNT.

When a table is accessed using an index, it must be decompressed in CU units every time. (However, this does not mean every row is decompressed. Decompressed data is reused for sequential rowids.) Therefore, when a table is accessed by using an index, it may be decompressed, which leads to performance degradation. If a table is accessed in row units, it is disadvantageous to use the TCC storage method. As with indexed access, the TCC storage is inefficient in all cases where access is row-by-row.

Overview

The Storage Data Map feature is a technology that allows for efficient use of disk bandwidth by reducing the amount of disk reads performed.

ZetaData automatically calculates the statistics (e.g.: maximum and minimum values of each column) for disks and preserves them in memory. This avoids reading disks that do not contain the data that do not satisfy the filtering conditions. Since the disk read size is decreased, the disk bandwidth can be used more efficiently as well as greatly reducing the amount of time consumed in disk I/O.

Operation

When querying data through Table Full Scan, physically contiguous disk areas are read. Here, the storage server calculates each column's maximum and minimum values for the disk area to configure a storage data map. When reading a specific disk block such as with table queries using indexes, the entire contiguous areas of disk are not read, so a storage data map is not created. Therefore, to increase performance, it is important to perform a Table Full Scan by not creating an index just like Function Offloading, or by using query hints.

Columns used to create a storage data map are limited to the columns that are contained in the WHERE clause of the view query amongst all columns in a table, as well as the columns that have not been preprocessed such as by functions or formulas.

The types of columns to be applied are not only NUMBER, CHAR, and VARCHAR but also most basic types that can be included in the WHERE clause without conversion. However, an LOB column is stored in a separate LOB segment, so this function cannot be used when a LOB column is included.

Since Function Offloading does not operate for LONG, RAW, and XML types, Storage Data Map is not available.

When the column is used in a WHERE clause, size comparison such as "large and small", as well as "same, different, NULL, and not NULL" can be expressed. If there is a large number columns, then storage data maps are created for up to eight columns, and then columns queried after are ignored.

When querying data stored for the first time after starting a storage server, there is no existing storage data map, which means no performance gain. As well, using a WHERE clause to repeatedly view a same column increases the performance. The WHERE clause used here does not need to be completely the same as the WHERE clause used when creating a storage data map, and performance increases as long as the columns used are the same.

A storage data map includes the maximum and minimum values of the columns for each disk area. If a condition of the WHERE clause is outside of the range of the minimum and maximum values, a read task may not be performed for the disk area.

Therefore, the lower the view query's selectivity is (in other words, the lower the number of data that meets the condition), the range of performance improvement becomes larger. As well, by storing data in the sorted format for the columns used in the WHERE clause, the difference between the column's maximum and minimum values becomes smaller, which means the impact of storage data map can be maximized.

A created storage data map is immediately removed from memory the moment in which a write request for the area is executed. This is because if data is modified, then the existing statistical value may be changed. Therefore, it is not recommended to use the storage data map in OLTP systems with a lot of data changes.

Since Storage Data Map operates when Function Offloading is enabled, disable Function Offloading by using its initialization parameter.

Overview

ZetaData uses InfiniBand for fast network communication between DB nodes and Storage nodes. Follow the steps below to set up a ZetaData network using InfiniBand.

1. Install the InfiniBand driver.

2. Verify the operation of the InfiniBand driver.

3. Configure kernel parameters.

4. Configure a network (refer to the network configuration manual of each InfiniBand manufacturer).

The figure below shows the IP address configuration for InfiniBand on the ZetaData node that will be used in the examples going forward.

To use InfiniBand, install a driver and library appropriate for the OS. Check the library by using each OS command and install it first.

The following is an example of installing a library for each OS.

Ubuntu

Install the package 'Development files for the libibverbs library' searched with the above command.

RedHat series (RHEL, CentOS, Fedora)

The following is an example of installing the InfiniBand driver on Red Hat 7,8 and 9 provided by Mellanox.

1. Install the Melanox driver.

1. Create a network configuration file for InfiniBand. Below is an example of the configuration file on DB node 0.

1. Execute the opensmd service for switches that do not support the subnet manager function.

1. Restart the server.

The following is an example of verifying the operation of the InfiniBand driver provided by Mellanox.

The current data warehouse market has reached its limits due to the explosion of data. The size of data is expanding beyond terabytes to petabytes, and the size of a single data warehouse will further increase the amount of data across the enterprise. This data growth eventually creates performance and cost issues.

In a data warehouse configured in a traditional storage area network (SAN) environment, the bottleneck is I/O performance. Typical storage I/O performance growth rates do not keep pace with data growth.

In addition, scalability is limited in a SAN environment. To solve this problem, you need to purchase more expensive equipment to reinstall DBs and migrate data. At some point, it will no longer be possible to scale-up and the existing data will need to be backed up externally or deleted. In other words, to address future data growth trends, horizontal scalability and high-speed access to large amounts of data are required.

One solution to this problem is Hadoop, which is open source in the "big data" market. Hadoop provides HDFS, an infinitely scalable file system, and the MapReduce framework for analyzing it. However, it is not as easy to use Hadoop to perform high-level analytics as a general-purpose RDBMS.

SSVR instances support flash devices as caches.

Flash devices provide fast I/O performance and non-volatile low storage space. There are two ways to write data to the cache: write-through and write-back, as shown in the figure.

This operation is completed by storing data in both disk and cache.

Node Specifications

All installation and configuration examples in this chapter are based on the specifications of the DB node and Storage node shown in the table below. The specifications of each node are the main factors that affect ZetaData configuration and system performance, so it is important to verify them before starting configuration.

There are several ways to check memory and disk capacity.

The following is an example of checking the physical memory capacity of nodes.

The following is an example of checking the memory capacity of a node.

It is assumed that a storage node has twelve 4 TB disks. The OS and the storage server's binary and control file are installed in 400 GB of space allocated to one of the disks.

If RAID is not used, then 3.6 TB of space (excluding the 400 GB where the OS is installed) is configured as a single partition. Therefore, the storage node can be configured by using the 3.6 TB partition of the disk in which the OS is installed, and eleven 4 TB disks.

It is assumed that a storage node has twelve 4 TB disks, and two of them are configured as RAID 1 mirroring. The OS and the storage server's binary and control file are installed in 400 GB of space allocated to the RAID1.

After installing the OS, divide the remaining 7.2 TB into two separate 3.6 TB disks, and configure RAID 0 for each one. Therefore, the storage node can be configured by using RAID 1 mirroring with two 3.6TB disks and ten 4TB disks, excluding the space where the OS is installed.

The following is the process of preparing shared disks for installation. The process must be performed on all nodes.

Storage node disks can be used by modifying their permission or ownership. However, this can cause the issue that a disk name is changed after OS rebooting. To prevent the issue, it is recommended to configure storage node disks by using udev.

The following briefly describes udev.

• Like system software, udev provides device events, manages device node permission, and creates or renames a symbolic link for a network interface or /dev directory.

• When a device is detected by the kernel, UDEV gathers properties such as the serial number or bus device number from the SYSFS directory to determine a unique name for the device. UDEV keeps track of devices in the /SYS file system based on their major and minor numbers, and utilizes system memory and SYSFS to manage device information.

• When the kernel raises an event when a module is loaded or a device is added or removed, UDEV follows the rules to set the device filename, create symbolic links, set file permissions, and so on.

The following is an example of storage node disks configured using udev.

The links with /dev/ in the above example are symbolic links created according to the udev rules.

The following is an example of the udev rules file for configuring disks.

The udev rules file must be saved with the .rules extension in the /etc/udev/rules.d folder.

The rule shown with the example means that the user should find the device that matches the specified SCSI_ID(RESULT=="SCSI_ID") among the block device (SUBSYSTEM=="block") nodes with the kernel name (KERNEL=="sda") expressed as sda, and then set the owner and user privileges and then create the given symbolic link.

The device SCSI_ID can be checked by executing /lib/udev/scsi_id (for RHEL 7).

Depending on the OS versions, execute /sbin/scsi_id. This program must be executed with admin privileges, and the following is an example of checking scsi_id.

For proper operation of ZetaData, several kernel parameters must be configured. The location of the kernel parameter configuration file is as follows.

The following is an example of configuring kernel parameters.

• It refers to the maximum value in bytes that can be allocated to a single shared memory segment.

• The value should be more generous than the size of the total shared memory to be allocated to the SSVR instance.

• It refers to the total number of pages of shared memory available system-wide.

• The value should be set based on the SSVR instance divided by the page size (reason: SSVR instance uses most of the system's shared memory resources generally.)

The following is the command to check the page size of the system.

• It refers to the maximum number of asynchronous I/O requests that the system can handle simultaneously.

• The value should be set to an appropriate value that monitors actual usage.

• It refers to the the maximum number of file descriptors that can be open simultaneously on the system.

• The value should be adjusted according to the scale of the system.

• It refers to the maximum number of memory mappings a process can have.

• When using RDMA over InfiniBand, maps are frequently generated during the process of registering internal library resources and regions to RDMA, so the value should be set generously.

To use a TCP socket for storage and DB node communication, configure the maximum size of the socket buffer as follows.

The following is the the environment variables for using an SSVR instance.

The initialization parameters to install ZetaData are basically the same as Tibero, and the following parameters should be configured.

The following is an example of setting the SSVR instance initialization parameters for Storage Node #0.

MEMORY_TARGET parameter is the total amount of memory to be used by the SSVR instance.

Due to the high amount of external memory used for connections on InfiniBand libraries (4 MB per connection), it is recommended to set this after consulting with the lab.

The formula is as follows:

TOTAL_SHM_SIZE parameter is the total amount of shared memory to be used by the SSVR instance.

The minimum value can be calculated by first adding the 3 GB required by default to start the SSVR instance, plus 150 MB per 1 TB of disk, and then adding 1 GB to 2 GB of other allowance per 10 GB of disk to the result.

To connect to a storage server by using tbSQL, configure the connection information in the $TB_HOME/client/config/tbdsn.tbr file.

The configuration method is the same as in Tibero with the exception that DB_NAME is not required.

The following is an example of configuring the file, $TB_HOME/client/config/tbdsn.tbr.

To configure SSVR instance, follow the following steps.

In this example, three storage nodes and two DB nodes will be configured in the following steps.

1. Create and start an SSVR instance

2. Create a storage disk

3. Create a grid disk

4. Create a flash cache

Below is the process of creating an SSVR instance based on the settings in $TB_HOME/config/$TB_SID.tip.

Check the contents of the initialization parameters and create a control file accordingly. Start the SSVR instance in nomount mode and create an SSVR instance. After creation, the SSVR instance is automatically shut down.

Start it in mount mode to restart an SSVR instance.

Storage Disk is the physical disk that will be used by the SSVR instance.

To use the disks on the Storage node, each disk must be registered as a storage disk for the SSVR instance.

The following is the command registering a storage disk.

Configure the storage disk capacity to 4 TB minus 400 GB for the disk where the OS, SSVR binary files, and control files are installed. The examples below assume installation on the first disk.

Storage disk information can be viewed through the V$SSVR_STORAGE_DISK view.

A Grid Disk is a disk that is visible from the outside of an SSVR instance and must be included in a single storage disk.

The following registers a grid disks.

The following is an example of creating a grid disk using the maximum available capacity of a registered storage disk by omitting the size option.

Grid disk information can be viewed through the V$SSVR_GRID_DISK view.

To improve I/O performance, register a flash device as a cache by using the following command.

The following is an example of creating a flash cache that has a path of "/dev/flash", a start number of 0, 1490GB of a flash device, and four devices. A flash cache cannot be used until a storage server is restarted after a flash cache is created. To use a flash cache, a storage server must be restarted.

Flash cache information can be checked through the V$SSVR_FLASHCACHE view

This section describes how to use SSVR instances on TAS and TAC to create disk space, tablespace, and install the DB.

To use SSVR instance in TAS and TAC instance, SSVR connection information must be configured.

In the "$TB_HOME/client/config/ssdsn.tbr" file, configure the network IP address of the storage node to be used for communication and the port information of the SSVR instance. This SSVR instance connection information needs to be set on all nodes where TAS and TAC instances are installed.

The following is a sample of the $TB_HOME/client/config/ssdsn.tbr file.

The next step is to configure the TAS instance and configure DiskSpace with the grid disks of SSVR.

Configure CM instances and use them with TAS instances for cluster configuration of TAC instances.

1. Configuring connection information for using TBSQL

2. Configuring TAS instance on DB node #0 and creating disk space

3. Configuring CM instance on DB node #0

4. Staring CM and TAS instance on DB node #0

The following is an example of a $TB_HOME/client/con fig/tbdsn.tbr file for connecting to SSVR instances, TAS, and TAC instances using tbSQL.

The TAS instance connects to the SSVR instance through the SSVR instance's connection information recorded in the $TB_HOME/client/config/ssdsn.tbr file, and identifies each disk by the grid disk name created in the SSVR. The TAS instance recognizes file paths that start with "-" as grid disks in SSVR and can use them in all cases, including creating disk space and adding/deleting disks.

The following is an example initialization parameters and configuration for a TAS instance.

The following is an example of the process of creating disk space using a grid disk in an SSVR instance.

AU (Allocation Unit) is a value that indicates the unit of allocation, and the size of the allocation unit that can be set is 4 MB. The striping units and the striping units of the TAS must be multiples of each other to ensure that the array fits and improve performance.

Disk space information can be checked through V$AS_DISKSPACE view.

The CM instance registers the network and cluster and registers TAS and TAC as services to help ensure reliable cluster operations.

The following is an example of setting initialization parameters for CM. For more information, refer to the "Tibero Administrator's Guide".

The following is an example of the process of registering a network with CM, registering a cluster, starting a cluster, registering a TAS service, registering a TAS instance, and starting a TAS instance after starting a CM instance.

The following is an example of the process of adding DB node #1 TAS from DB node #0 TAS instance.

The following is an example of setting TAS instance initialization parameters for DB Node #1.

The following is an example of initialization parameter settings for CM instance on DB node #1.

The following is an example of starting a CM instance on DB node #1 and going through the process of network registration, cluster registration, cluster startup, TAS service registration, TAS instance registration, and TAS instance startup.

The TAC instance connects to the SSVR instance through the SSVR instance connection information recorded in the $TB_HOME/client/config/ssdsn.tbr file. The TAC instance recognizes file paths that start with a "+" as virtual files managed by the TAS instance. This path can be used for the path of any file, including control files and CM files.

The following is an example of initialization parameters for the configuration of DB node #0 TAC instance as a cluster using TAS. Do not modify the 'DB_BLOCK_SIZE=32K' parameter.

The MEMORY_TARGET parameter is the total amount of memory to be used by the TAC instance.

Due to the high amount of external memory used for connections in InfiniBand libraries (4 MB per connection), it is recommended that you consult your lab before setting this parameter.

The formula is as follows:

The following is an example of the process of registering the TAC service and registering the TAC instance on the CM instance of DB node #0 that was started in the previous step.

The following is an example of the process of creating a melt database by starting the TAC instance on DB node #0 in nomount mode and using the disk space of the TAS instance. It will automatically shut down after creation, so restart it.

The following is an example of adding additional configuration on DB Node #0 TAC instance to start DB Node #1 TAC instance.

The following is an example of setting the initialization parameters for DB Node #1 TAC instance. Do not modify 'DB_BLOCK_SIZE=32K'.

The MEMORY_TARGET parameter is the total amount of memory to be used by the TAC instance.

Due to the high amount of external memory used for connections in InfiniBand libraries (4 MB per connection), it is recommended that user consults tech service team before setting this parameter.

The formula is as follows:

The following is an example of registering and starting a TAC instance on the DB Node #1 CM instance that was started in the previous step.

Through the above process, configure SSVR instances, TAS instances, and TAC instances on three SSVR nodes and two DB nodes respectively.

The following views display SSVR instance information. They can be retrieved only in a SSVR instance.

The V$SSVR_CLIENT view shows information about all clients that the SSVR instance has connections to.

The following is an example of V$SSVR_CLIENT.

The V$SSVR_FLASHCACHE view shows information about all flash caches connected to an SSVR instance.

The V$SSVR_GRID_DISK view shows information about all grid disks attached to an SSVR instance.

The V$SSVR_STORAGE_DISK view shows information about all storage disks attached to an SSVR instance.

The V$SSVR_SLAB_STAT view shows the SLAB information that the SSVR instance is currently using.

The following is an example of V$SSVR_SLAB_STAT.

The V$SSVR_MEMSTAT view shows memory usage information for an SSVR instance. The units are expressed in MB.

The following is an example of V$SSVR_MEMSTAT.