[INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara)

ミッションクリティカルを実現する
国産データベースＨｉＲＤＢの技術（ハイアールディービー）

2011/09/27

2011/10/20
株式会社日立製作所情報・通信システム社
ソフトウェア事業部 DB設計部
原憲宏

© Hitachi, Ltd. 2011. All rights reserved.

１．ＷｈａｔｉｓＨｉＲＤＢ

２．スケーラビリティを高めるＨｉＲＤＢの技術と特長

３．障害発生時の可用性を高める
ＨＡクラスタの技術と特長

４．読み取り一貫性の再考

５．おわりに


１-１データベースは社会インフラの要
金融公共・教育

世の中の重要な社会インフラは
ＩＴ基盤なしには支えられない
通信
流通・製造

データベース

ＩＴ基盤の要はデータベースマスコミ
交通・運輸

データベースの信頼性が
ＩＴ基盤の信頼性につながる

© Hitachi, Ltd. 2011. All rights reserved. 2

１-２信頼性とスケーラビリティを追求してきたＨｉＲＤＢ

「止めない」設計思想を貫く
高信頼スケーラブルデータベース
ハイアールディービー

Highly Scalable Relational DataBase
Hi

社会基盤を支えるために
日立が自社開発にこだわり続ける
純国産ＲＤＢＭＳ


１-３データベースに対する日立の取り組み

オープンシステムで進化
進化メインフレーム(ＭＦ)での発展累計出荷７６,０００サーバ
’10/1 ’10/4 ※11年3月(10年度末）時点の累計出荷台数

XDM/RD V12 ■クラウド時代を支える
高性能・高信頼データベースへ
’05/1
’06/6
銀行や交通、公共分野の XDM/RD V11 HiRDB V8 ■ ビジネスの急速な変化に対応する
柔軟性を兼ね備えた、情報統合基盤と
オンラインを止めない基盤 ’03/8 ’03 高信頼ノンストップデータベースへ
が欲い！ XDM/RD V10 HiRDB V7 ■ ノンストップビジネスに応える
耐障害性と可用性を追及
’02/9 ’01
HiRDB V6 ■ネットビジネス（24×7運用）
社会インフラを支える
XDM/RD V9
に応える長時間連続運転の更なる強化
究極の信頼性の追求～’99
～’
’95～’
XDM/RD ■ミッションクリティカル向け機能･性能強化
～
HiRDB V2～5
■デジタルコンテンツの拡張
ＭＦ技術の継承・Universal Server リリース
’94
RDB1
HiRDB V1 ■オープンシステム向けミッションクリティカル向けデータベース
XDM/SD ・ＳｈａｒｅｄＮｏｔｈｉｎｇでのパラレルサーバリリース
メインフレームの
ADM オープンでの
安心感をそのままに、
PDM
オープンプラットフォーム高信頼性の追求
に対応したい！時代
１９７０１９９０２０００２０１０


１-４本日のテーマ

ミッションクリティカルを実現する取り組み

１．スケーラビリティをビジネス規模が拡大してもサービスレベル
高めるを維持するＨｉＲＤＢの技術と特長

２．可用性を高める障害発生時も業務を継続する

３．データの整合性を
確保する読み取り一貫性の再考


２．スケーラビリティを高めるＨｉＲＤＢの技術と特長


２-１サービスレベルを維持するために
取り扱う業務量やデータ量が増加しても、
サービスレベルを維持し続けたい。
性
性能向上
能
■ＳｈａｒｅｄＮｏｔｈｉｎｇアーキテクチャ並列処理で性能向上
並列数
・ハードウェアの能力を最大限に引き出せる。
・並列処理で処理時間を短縮できる。

ＡＰサーバデータベースを
・・・分割する
・完全独立で、サーバ間の共有リソースなし。
・データ量の増大に対応して拡張しやすい。

ＤＢサーバ
・・・

ストレージ
パーティション（分割）表１００台規模構成
での実績あり


２-２分割したサーバの独立性を確保するために

ＤＢをアクセスするＢＥＳ(*1)が、分割されたデータを独立に処理する
ＦＥＳ(*2)がＳＱＬを振り分け、業務ＡＰにデータの所在を意識させない

完全独立

業務ＡＰは、
業務ＡＰデータの所在を意識しない
ＡＰサーバＦＥＳ１ＦＥＳ２
ＦＥＳｎ
・データの所在位置はＦＥＳで自動認識。
・ＢＥＳが受け持つデータを並列に処理。
・ＢＥＳの処理結果をＦＥＳが纏めて返却。

ＤＢサーバＢＥＳ１ＢＥＳ２ＢＥＳｍ

排他プール

ＤＢバッファ
ＤＢアクセスに必要なリソー
ストレージスが独立し、競合が無い
パーティション
*1 : ＳＱＬ受付サーバ
ＦＥＳ（分割）表
(Front End Server)
更新ログ
*2 : ＤＢアクセスサーバ
ＢＥＳ
(Back End Server)

２-３トランザクションの並列実行度を高められる

分割したデータ単位に、業務を独立して実行させることで、
高トラフィック時にもスループットを確保できる。

トランＡ

トランＢ
表の分割単位に独立
関東関西その他してＤＢをアクセス
集計業務集計業務集計業務
ＡＰサーバ
ＦＥＳ１・・・ＦＥＳ３・・・ＦＥＳ８

高トラフィック時も
ＤＢサーバＢＥＳ１ＢＥＳ３ＢＥＳ８
・・・・・・スループットを確保

ストレージパーティショニング（分割表）
表の分割キーの例関東関西その他

ＤＢ格納領域１ＤＢ格納領域３ＤＢ格納領域８


２-４ＳＱＬの並列実行度を高められる

複数のサーバを跨ぐＳＱＬは、表の分割単位に処理を分解することで
ＢＥＳでの並列実行度を高め、レスポンスタイムを向上できる。

ＳＱＬをＢＥＳ単位の処理
に分解し並列実行

ＳＱＬ
検索、更新、ジョイン、ソート、
グループ化、集合演算処理

全店舗パイプライン並列
集計業務
ＡＰサーバジョイン、ソートなどの負荷の高い
ＦＥＳ１・・・・・・処理をＦＥＳが更に分解して順次
処理。

Ｉ/Ｏ並列、サーバ間並列
ＤＢサーバＢＥＳ１ＢＥＳ３ＢＥＳ８
・・・・・・分割した表を並列に検索・更新。

ストレージパーティショニング（分割表）
表の分割キーの例関東関西その他レスポンスタイムを向上
ＤＢ格納領域１ＤＢ格納領域３ＤＢ格納領域８


２-５日付と支店番号でのＤＢ分割の例

月単位に支店グループを２次元分割
独立したＢＥＳで並列に処理

関東関西その他
空間軸での
ＢＥＳ１ＢＥＳ２ＢＥＳ３分割

支店売上管理表
第１次元第２次元＜関東地区＞＜関西地区＞＜その他地区＞
分割列分割列支店番号支店番号支店番号時間軸での
～1999 2000～2999 3000～
日付地区支店支店番号売上・・・分割
2011-07-30 関東東京 1001 DBAREA1 DBAREA2 DBAREA3
2011-07-30 関西大阪 2001 関東07 関西07 他07
＜７月＞
2011-07-30 九州福岡 3010
・・
DBAREA4 DBAREA5 DBAREA6
2011-08-30 関東 1010
＜８月＞
2011-08-30 東 4001 関東08 関西08 他08
2011-08-30 関西京 2008
・・一定期間保管
2011-09-30 関東東京 1001
関東09 関西09 他09
＜９月＞
2011-09-30 関西 2015
・・


２-６ＤＢ格納領域の簡単なローテーション運用

ＤＢの格納領域を、月次で簡単に再利用。

■従来の運用
ＤＢ格納領域の
削除・追加が大変
＜７月＞

関東10
＜１０月＞
ローテーション運用を容易にす
る『月別ハッシュ分割』の利用
＜７月＞＜７月＞⇒＜１０月＞
関東07 関西07 他07

＜８月＞月別 DBAREA4 DBAREA5 DBAREA6
ハッシュ関東08 関西08 他08 ＜８月＞
分割
＜９月＞

関東09 関西09 他09 ＜９月＞
＜１０月＞
＜関東地区＞＜関西地区＞＜その他地区＞
支店番号支店番号支店番号
～1999 2000～2999 3000～


２-７ＤＢ格納領域の簡単な容量設計、運用管理

ＤＢ格納領域の見積もり、運用がどれだけ必要？大変？

■従来の運用 ■ストレージ機能と連携した
シン・プロビジョニングでの運用
＜関東地区＞＜関西地区＞＜その他地区＞ DBAREA1 DBAREA2 DBAREA3
支店番号支店番号支店番号
最大
～1999 2000～2999 3000～
予備予備オンデマンド
仮想Voｌ(ディスク)
・仮想ディスクに最大サイズでＤＢ
ディスク追加
エリアを確保でき、ＤＢ容量設計
が容易。
見積もり、設計が大変・ＤＢエリアの自動拡張に伴い、
ストレージオンデマンドでストレージを割り
プール
・データ増加を予測した見積もり設計。当てられる。
・それに伴う拡張・運用設計の立案。・ストレージプール全体で枯渇
・ＤＢエリアのパンク回避のための余裕値設計。ＨＤＤ監視でき、監視、拡張運用が容易。

監視、運用が大変
ストレージプールを活用した
・個々のＤＢエリアの監視。資源共有により負担を軽減
・ディスク追加によるＤＢエリア拡張。

２-８マスタ表の効率的なアクセス

マスタ系データの配置は？


全ＢＥＳから参照できる
ＦＥＳ１ＦＥＳ２ＦＥＳ３
ＡＰサーバ『共用表』を利用
・全ＢＥＳから参照できる表属性。
・各ＢＥＳのバッファで独立して参照できる。
・複数のＢＥＳから参照する場合でも、
ＤＢサーバＢＥＳ１ＢＥＳ２ＢＥＳ３ＢＥＳ間での通信はおこなわない。
ＤＢバッファＤＢバッファＤＢバッファ
マスタマスタマスタ

DBAREA10
特定ＢＥＳへのアクセス
ストレージ集中を回避できる
商品マスタ
共用表属性


関東関西他


２-９マスタ表の効率的なアクセス（続き）
『共用表』の更新
- 更新要求をＦＥＳが受け、全ＢＥＳに配布。バッファを更新。
- 受け持ちＢＥＳだけがストレージ上のデータを更新。
更新

ＦＥＳ１ＦＥＳ２ＦＥＳ３
ＡＰサーバ

受け持ちＢＥＳ

ＢＥＳ１ＢＥＳ２ＢＥＳ３
ＤＢサーバ
ＤＢバッファ
マスタ
ＤＢバッファ
マスタ
ＤＢバッファ
マスタ
ＤＢサーバの独立性を
関東関西その他確保する
・共用表の更新要求を全ＢＥＳに配布。
ストレージ
DBAREA10 ・バッファヒットしない場合はストレージから
商品マスタ読み込んでバッファを更新。
共用表属性・受け持ちＢＥＳだけがストレージ上の
データを更新。
・更新ログは全ＢＥＳで出力。
関東関西他


３．障害発生時の可用性を高める


３-１サービスを提供し続けるために

障害が発生しても、サービスを提供し続けたい

障害発生時、業務を継続するための３つの観点

③障害を気付かせない
②素早く切り替える

待機系

①障害箇所の局所化

・障害の発生サーバのみに影響を実行系
局所化でき、他の稼動中サーバへ
の影響なし。
・全面ダウンに繋がらない。ＤＢＤＢＤＢ
ログログログ



３-２素早い『検知・引継ぎ・回復』による数秒での切り替え

『検知・引継ぎ・回復』の３つのポイントの高速化で、数秒オーダでの
系切り替えを実現。

実行系（ａ）素早く検知待機系（ｂ）素早く引継ぎ

障害

ＨｉＲＤＢＨＡＨＡＨｉＲＤＢ
（ｃ）素早く回復
モニタモニタ
Ａｌｉｖｅ監視

フェイルオーバ時間 ※1

ＨＡＢｏｏｓｔｅｒＰａｃｋＨＡＢｏｏｓｔｅｒＰａｃｋ

数秒オーダ
高速系切り替え
時間

▼トランザクション決着 ※2
▼障害検知

ＤＢ
▼メモリ状態の復元（ＤＢ回復）
▼リソース切り替え ▼システムプロセスの初期化

ログ ※1：障害発生～新規トランザクション受付開始までの時間。
※2：トランザクション決着時間はシステムログ量に依存。

※ ＨＡモニタ、ＨＡＢｏｏｓｔｅｒＰａｃｋ：クラスタウェア


３-３（ａ）素早く障害を検知する

マシンダウンクラスタウェア間でのＡｌｉｖｅ監視による検知
ＯＳパニックＨＡＢｏｏｓｔｅｒＰａｃｋでの通知による瞬時検知
ＨｉＲＤＢダウンＨｉＲＤＢ自らの申告によるゼロ秒検知

マシンダウン実行系待機系

監視
ＨｉＲＤＢＨＡＨＡＨｉＲＤＢ
モニタモニタ
ＨｉＲＤＢ障害申告Ａｌｉｖｅ監視

監視
ＨｉＲＤＢスローダウン Time
Stamp

ＯＳパニック通知

・実行系のマシンダウンを、ＨｉＲＤＢのスローダウンを、生存監視
待機系からのハートビートで検知。ＤＢ機能（Time Stampの定期更新/定期参照）に
・待機系から実行系マシンをリセット。ログ
より、ＨＡモニタが検知。



３-４（ｂ）素早くリソースを引き継ぐ

共有ディスクの数に依存しない、短時間でのディスク引継ぎ：
①ＨＡＢｏｏｓｔｅｒＰａｃｋがＨｉＲＤＢのＩ/Oに介在し、
実行系からのアクセスのみを許可。
②障害発生時、アクセス制御の変更のみで引継ぎを実現。
実行系待機系
ＨＡＨＡ
モニタモニタ

ＨｉＲＤＢＨｉＲＤＢ


・・・・・・

①I/O介在での
アクセス制御

常時オンライン
（活性）状態ＤＢ
ＤＢログ
ＤＢログ
ＤＢログ
ログ


３-４（ｂ）素早くリソースを引き継ぐ

共有ディスクの数に依存しない、短時間でのディスク引継ぎ：
①ＨＡＢｏｏｓｔｅｒＰａｃｋがＨｉＲＤＢのＩ/Oに介在し、
実行系からのアクセスのみを許可。
②障害発生時、アクセス制御の変更のみで引継ぎを実現。
実行系待機系
ＨＡＨＡ
モニタモニタ
HA Booster Packなし HA Booster Packあり
ＨｉＲＤＢＨｉＲＤＢ
シ
非活性化

ー

アクセス
実行系

拒否
ケＨＡＢｏｏｓｔｅｒＰａｃｋＨＡＢｏｏｓｔｅｒＰａｃｋ
ンディスク一
活性化括
シ処
ャ・・・・・・
ル理
処
アクセス
②アクセス制御
活性化

許可

理待機系
ディスクの変更（引継ぎ）
切切
替替
時時
間間
共有ディスク数共有ディスク数
ＤＢ
ＤＢログ
ＤＢログ
ＤＢログ
ログ


３-５（ｃ）素早くＨｉＲＤＢを回復させる

ホットスタンバイㄤ高速ＤＢ回復でＨｉＲＤＢを高速再開始
- ホットスタンバイ ①システムデーモン、ＤＢ処理プロセスの開始
- 高速ＤＢ回復 ②ディスクの並列ＤＢ回復
③新規トランザクションの早期受付開始

③新規トランザクションの
待機系⇒実行系早期受付開始
①ホットスタンバイ
・システムデーモン
・ＤＢ処理プロセス

ＨＡＨｉＲＤＢ
モニタＤＢ回復
ホットスタンバイ（ディスク１）
再開始ＤＢ回復
（ディスク２）
ＨｉＲＤＢ再開始
（ＤＢ回復）：
：
ＤＢ回復
（ディスクｎ）
ＨＡＢｏｏｓｔｅｒＰａｃｋ
時間

②ディスクの回復トランザクション
メモリ状態の復元トランザクションの
並列ＤＢ回復（ＤＢ回復処理）決着新規トランザクション

ＤＢ
ログ © Hitachi, Ltd. 2011. All rights reserved. 22

③障害発生を気付かせない

３-６トランザクションキューイング

系切り替え中に受け付けた新規トランザクションを待機させること
により、アプリケーションに障害発生を意識させない
（トランザクションキューイング）。

トランザクションキューイング
障害発生をトランザクション
系切替え期間
気付かせない受付
キュー

業務ＡＰ

ＦＥＳ
サービス再開
まで待機
実行
待機系

ＢＥＳ

ＢＥＳＢＥＳＢＥＳ受付非用
実行系
エラー

ＤＢＤＢＤＢマシンダウン
ログログログ



３-７Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタでのサービスレベル維持
切り替えをＢＥＳに複数の稼中ノードに分することにより、
障害時における切り替えの性能化を最限にえ、
安定性能を維持できる。
待機用サーバマシンが要なため、資対果の高いシステム
を実現できる。
■通常時 ■１台障害発生時
業務ＡＰ業務ＡＰ

ＤＢサーバ１ＤＢサーバ２ＤＢサーバ３ＤＢサーバ１ＤＢサーバ２ＤＢサーバ３

ＢＥＳ１ＢＥＳ３ＢＥＳ５ＢＥＳ１ＢＥＳ３ＢＥＳ５
ＢＥＳ２ＢＥＳ４ＢＥＳ６ＢＥＳ２ＢＥＳ４ＢＥＳ６
ＢＥＳ１ＢＥＳ２
障害
ＤＢ及システムログ
引継ぎㄤ継続用

ＢＥＳ単位でＤＢサーバ２、ＤＢサーバ３で
系切り替え( 動) 処理を分して引き継ぐ。
⇒分引継ぎサーバ間の負荷は化。


３-８Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタでのサービスレベル維持

複数ノードに障害が発生した場合でも、第２、第３の稼動中の
ＤＢサーバに処理を引き継ぐことで、
重障害でも、ＨｉＲＤＢはまること無くサービスを提供し続ける。

■１台障害発生時 ■さらに障害発生時
業務ＡＰ業務ＡＰ

ＤＢサーバ１ＤＢサーバ２ＤＢサーバ３ＤＢサーバ１ＤＢサーバ２ＤＢサーバ３

ＢＥＳ１ＢＥＳ３ＢＥＳ５ＢＥＳ３ＢＥＳ５
ＢＥＳ２ＢＥＳ４ＢＥＳ６ＢＥＳ４ＢＥＳ６
ＢＥＳ１ＢＥＳ２ＢＥＳ１ＢＥＳ２
障害障害
ＢＥＳ３
ＢＥＳ４
ＢＥＳ１

ＤＢサーバ２の障害発生時は、
ＨＡモニタ（マルチスタ
ＤＢサーバ３で処理を引き継ぐ。
ンバイ機能）との連携
重障害でもノンストップ

４．読み取り一貫性の再考


４-１読み取り一貫性とは

他トランザクションで更新中のデータに対する検索を、
待つことなしに実行できてうれしい。
確定の最新のデータを返す。

更新トランザクションが排他を
取して更新中のデータ。待たに検索できる。

更新トランザクション更新データ
1 2
ㅒＰＤＡＴＥ１Ａ⇒ㅕ
A⇒
2 参照トランザクション
２Ｂ
Ａ
３ ㅀ ＳＥＬＥㅀＴ

A
ＳＥＬＥㅀＴ開始時点で確定のデータ
ㅀＯＭＭＩＴ
を参照する。


４-２読み取り一貫性の検証～(１)ＣＯＭＭＩＴの前後～
参照結果はㅀＯＭＭＩＴとＳＥＬＥㅀＴの開始タイミングに依存。
ㅀＯＭＭＩＴでも、ㅀＯＭＭＩＴにＳＥＬＥㅀＴを開始していると、
更新データを返す。

読み取り一貫性
更新トランザクション参照トラン１参照トラン2
SE E T
SE E T
A

ㅒＰＤＡＴＥ
SE E T A
A⇒
SE E T 開始が
A O ITのかかで
時 SE E T 結果がなる。
間 ㅀＯＭＭＩＴ
SE E T
A
O IT でもそのに
SE E T を開始していると
更新データを返す。


４-３読み取り一貫性の検証～(２)ＲＯＬＬＢＡＣＫの前後～

参照結果はＲＯＬＬＢＡㅀㅈ とＳＥＬＥㅀＴの開始タイミングに
非依存。

更新トランザクション参照トラン１参照トラン2
SE E T
SE E T
A

ㅒＰＤＡＴＥ
SE E T A
A⇒

A
時 SE E T
SE E T 開始が
間 RO BA RO BA のかかで
SE E T
A 結果は変わらない。
A


４-４読み取り一貫性の検証～(３)順次参照の組み合わせ～

ㅀＯＭＭＩＴと２つのＳＥＬＥㅀＴそれれの開始タイミングに
よては、ましくない参照結果となる。

更新トランザクション参照トラン１
SE E T
A 更新データの値
データの値
ㅒＰＤＡＴＥ（データ１、データ２）
データ１データ２
データ１ SE E T
トランザクション
A⇒ B 参照トラン2
2 更新Ａ、Ｂ
SE E T
A 更新 ㅕ、ㅖ
SE E T

時 B
ㅒＰＤＡＴＥ
間データ２

B⇒ 参照トラン3
3

ㅀＯＭＭＩＴ
SE E T 参照トランザクション３
A
では、ましくない結果
SE E T
(Ａ、ㅖ）となる。


４-５排他なし検索含めての検証～(１)COMMITの前後～
読み取り一貫性でも、排他なし検索（ itho t lock no ait）でも、参照結果は
O IT とSE E T の開始タイミングに依存。
O IT をに意識する業務でなけれ、を意識する必要はない。

読み取り一貫性排他なし検索
更新トランザクション参照トラン１参照トラン2 参照トラン１参照トラン2
SE E T SE E T
SE E T SE E T
A A

ㅒＰＤＡＴＥ
SE E T A SE E T A
A⇒

A A UPDATEのかで
時 SE E T SE E T
結果がなる
間 ㅀＯＭＭＩＴ
SE E T SE E T
A

O ITのかで
結果がなる


４-６排他なし検索含めての検証～(２)ROLLBACKの前後～
排他なし検索のケースでは、参照結果はUPDATE とRO BA の
開始タイミングに依存。
UPDATE とRO BA の開始タイミングをに意識する業務
でなけれ、を意識する必要はない。
更新トランザクション参照トラン１参照トラン2 参照トラン１参照トラン2
SE E T SE E T
SE E T SE E T
A A

ㅒＰＤＡＴＥ
SE E T A SE E T A
A⇒

A
時 SE E T SE E T

間 RO BA
SE E T SE E T
A

A A

UPDATEとRO BA の UPDATEとRO BA の
で結果は変わらないで結果がなる


４-７排他なし検索含めての検証～(３)順次参照の組み合わせ～

読み取り一貫性でも、排他なし検索でも、２つのデータを順次ＳＥＬＥㅀＴする
ケースでは、これら２つのデータの整合性は保されない。

更新トランザクション参照トラン１参照トラン１
SE E T SE E T
A A
ㅒＰＤＡＴＥ
データ１ SE E T SE E T
A⇒ B 参照トラン2
2 B 参照トラン2
2
SE E T SE E T
A
SE E T SE E T

時 B B
ㅒＰＤＡＴＥ
間データ２

B⇒ 参照トラン3
3 参照トラン3
3
SE E T SE E T
ㅀＯＭＭＩＴ A
SE E T SE E T


４-８読み取り一貫性における考察

読み取り一貫性でも、排他なし検索でも、
参照結果は O IT とSE E T の
開始タイミングに依存。

データの整合性をに意識する業務では、
排他を取してから参照する必要がある。


４-９結論

読み取り一貫性では、他のトランザクションの
更新完を待たにデータを参照でき、力。

O IT のデータ整合性をに意識する
必要のない業務では、排他なし検索とのを
意識する必要はない。

データ整合性の性が求められる業務では、
排他を取してから参照する必要がある。


４-９結論

ＨｉＲＤＢでは、業務の特性に応て、
ＳＱＬに性を定可能。

■HiRDBでの性の定

性
HiRDBにおける実現
（Ｉsolation level）
READ UNCOMMITTED 検索時の排他オプションに
（コミットデータの読込み）「WITHOUT LOCK NOWAIT」を定
READ COMMITTED 検索時の排他オプションに
（コミットみデータの読込み）「WITHOUT LOCK WAIT」を定
REPEATABLE READ 検索時の排他オプションに
（り返し可能の読込み）「WITH SHARE LOCK」を定
SERIALIZABLE LOCK TABLE を用いて、
（列化可能）表に対して排他をかける


５．おわりに


５-１国産データベース技術の発展に貢献しています

日データベース会(DBS )から、長年にる継続な独自データベース管理システムの
究開発と産業におけるデータベース管理システムのな値向上へのを
認められ、２０１０年度に新設された業績の第一号を受しました。

日データベース会(DBS ) 業績とは
業績は、が国のデータベースに関する・技術の産業化をはかり、もて
術、化、産業の発に大いにした体の業績をするためのものです。
業績は各年体を定して表するものではなく、な績があた体が
あれ表する制度です。


５-２おわりに

これからも国産のＨｉＲＤＢに
期待ください！

の会社、製品は、それれの会社の商もしくは鉇商です。


[INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara)

[INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à [INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara)

Similaire à [INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara) (20)

Plus de Insight Technology, Inc.

Plus de Insight Technology, Inc. (20)

Dernier

Dernier (8)

[INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara)