522
淺談TimesTen內存數據庫的結構
TimesTen主要用於以下部署方式：
- 用於獨立的OLTP係統的內存數據庫
- 用於Oracle物理數據庫的內存緩存數據庫
- 在Oracle Exalytics的內存分析
一般行業內，大多采用第一種和第二種方式使用TimesTen數據庫。
文件結構
TimesTen數據庫主要包括的文件有：
1、檢查點文件
主要用來記錄和同步Data Store的內存數據，是內存在磁盤上的一個鏡像，類似於oracle數據庫的數據文件。每個TimesTen實例有兩個檢查點文件，在做檢查點操作的時候會交替寫入這兩個文件，兩個檢查點文件之間的存在一定的時間間隔。
在TimesTen數據庫中，有兩種類型的檢查點：
- 非阻塞檢查點：非阻塞檢查點也被稱為模煳檢查點。這些檢查點的頻率可以通過應用程序進行調整。非阻塞檢查點不需要數據庫上的任何鎖，因此在檢查點操作正在進行時，多個應用程序可以在同一數據庫上異步提交或回滾事務，它是一個不完全檢查點，不必保證事務的一致性。
- 阻塞檢查點：做該檢查點操作時會加上數據庫級別的鎖，它是一個完全檢查點，必須保證事務的一致性。
2、事物文件
其主要作用為：
a、用於發生係統故障時，重做事務
b、用於撤消回滾的事務
c、將更改的內容複製到其他TimesTen數據庫
d、將更改的內容複製到Oracle數據庫
e、允許應用程序通過XLA接口監視對表的更改
事物日誌文件存放路徑位於配置文件中logdir參數所指定的目錄下，當完成以下操作後，TimesTen會自動清除事物日誌文件：
將日誌記錄寫入事務日誌文件(或以前的事務日誌文件)的所有事務都已提交或回滾。
事務日誌文件中記錄的所有更改都已寫入檢查點文件。
如果使用複製功能，事務日誌文件中記錄的所有更改都已複製到對端。
如果已經為該行為配置了TimesTen緩存，則事務日誌文件中記錄的所有更改將被傳播到Oracle數據庫。
如果使用XLA，事務日誌文件中記錄的所有更改都已報告給XLA應用程序。
3、配置文件
TimesTen服務器端的配置信息都被記錄在sys.odbc.ini文件中，包括：服務器端基本配置和各個Data Store的初始化參數，Data Store裝載時會讀取該配置文件中的相關配置；連接DSN時也會讀取該文件中的信息。
客戶端連接的配置信息則被記錄在sys.ttconnect.ini文件中，如果需要使用C/S連接模式，就需要配置該文件。
ttendaemon.options則用來記錄TimesTen主進程所需要的配置信息也就是實例信息，包括後台日誌目錄、日誌大小、C/S連接端口號、TNS_ADMIN目錄等，修改該文件需要重啟守護進程。
4、警告日誌文件
ttmesg.log記錄的是TimesTen運行情況的日誌記錄，有些類似於Oracle的alert.log文件；tterrors.log則記錄的是報錯信息。ttmesg.log和tterrors.log都可以通過設置ttendaemon.options配置文件中的參數來控製每個文件的大小、個數、存放路徑等。
內存結構
如上圖所示，TimesTen的內存結構主要分為PermSize、TempSize、LogBuffer和64M的DB header
PermSize：Data Store，保存所有數據庫數據的區域，我們將其視為一個獨立的數據庫。
LogBuffer：用於暫時存儲記錄Data Store變更的日誌，類似於Oracle的SGA共享內存區域的日誌緩存（Log Buffer）
TempSize：臨時存儲執行計劃等數據的共享區域，排序等等操作臨時使用。相比與Oracle，TimesTen在此處作出了結構上的簡化，可以視為Oracle的多個內存區域的合集，也正因為這樣的簡化，TimesTen在使用上相當於就必需保證簡單化，否則爭用熱點出現，其性能甚至可能不如Oracle數據庫。
由於這三個參數都是基於Data Stone的，所以對應的配置文件是sys.odbc.ini文件，我們可以通過修改sys.odbc.ini文件，來指定每一個DS在加載的過程中，需要分配多大的內存。在已經運行的環境下，可以通過dssize –m的命令，看到每一個區域所使用的內存大小，以及最高水位線（如下圖）。
對於PermSize的大小，可以用過ttSize和ttComputeTabSizes來計算出，而TempSize的大小沒有工具可以進行計算，在TimesTen數據庫負載工作時，觀測TEMP_IN_USE_HIGH_WATER的大小。PermSize和TempSize的調整，都需要從內存中卸載TimesTen數據庫以進行更改，並且PermSize大小如果縮小，需要重新創建TimesTen數據庫。
後台進程
在後台進程中，我們可以分為常駐進程和可選進程兩種：
1、主守護進程（Daemon）
主要負責的工作有啟動subdaemon,ttcserver(listener),
內存管理的policy(inuse,manual,alawy)和共享內存的請求，進程的恢複和啟動相應的agent。在係統中安裝的每個TimesTen 實例上都運行了一個主守護程序進程。應用程序通過TimesTen ODBC 或JDBC驅動程序建立了到主守護程序的“deadman”套接字連接。
2、子守護進程（Sub Daemon）
子守護進程是由主守護進程產生的子進程，用於管理內存中加載的Data Store。每個活動的Data Store（已加載到內存中的存儲）都有一個子守護程序進程。主要功能有，負責加載和卸載Data Store，監視死鎖、衝刷事務處理日誌緩衝區、事務回滾、處理過期數據、檢查點以及在係統故障後恢複Data Store等。子守護進程是一個多線程的進程結構，通過ttstatus可以看到當前的subdeamon的線程（如下圖）：
3、ttcserver(listener)
該進程主要要是偵聽用戶請求，然後通根據用戶請求的DSN轉發到相應的subdaemon，這個進程為每個連接生成一個ttcserver進程來執行應用程序的各種請求。功能類似於oracle數據庫的listener進程。在TimesTen 11的版本裏，默認的配置，該進程在53397的端口上偵聽，用戶可以通過ttmodinstall來進行修改，在TimesTen7版本中，該進程在17003的端口上偵聽（如下圖）：
4、ttcserver(用戶)
這種進程是具體負責執行應用程序請求的進程，比如執行sql，讀取數據等等，由ttcserver(listener）負責啟動。
5、timestenrepd：
Replication進程用於管理主備複製、AWT同步的複製進程，該進程會派生並並管理複製持有日誌進程、XLA父進程、接受進程、傳送進程、Failover進程以及複製監聽進程等子進程。該進程是可選進程，隻有在開啟複製關係時，才會存在。進程也是多線程結構（如下圖）：
6、timestenorad：
Cache Agent進程用於管理Cache Group同步的進程，實現TimesTen與Oracle之間的數據同步；該進程會派生並管理句柄進程、刷新時間管理進程、刷新進程以及清理進程等子進程。該進程是可選進程，也是多線程結構（如下圖）：
7、其他可選進程：
FullBackup進程用於內存數據庫全庫備份、Bulkcp進程用於內存數據庫數據導入導出、XLA進程用於Transaction Log的API接口進程。
TimesTen高可用
對於目前大多數業內環境，TimesTen的部署方式大多采用以下兩種方式：TimesTen為主，進行應用業務的支撐，同時自動同步到oracle數據庫中；另一種是oracle數據庫為主要業務支撐環境，TimesTen隻支持應用讀取的功能。
在采用第一種部署中，oracle官方建議使用以下方式進行高可用環境的搭建，即TimesTen主庫進行業務的事物支撐，在它的同步複製的備庫，對外提供業務讀取和向oracle數據庫環境同步的功能（如下圖）。
原文發布時間為：2017-11-6
本文作者：朱亮
本文來自雲棲社區合作夥伴“數據和雲”，了解相關信息可以關注“數據和雲”微信公眾號
最後更新：2017-11-06 14:04:27