DBMotoでのMicrosoft SQL Server 2017 on Linuxとの接続検証

Microsoft SQL Server 2017 on Linuxがリリースされ、Linux環境上でもMicrosoft SQL Serverを動作させることができるようになりました。
Linux版リリースによってMicrosoft SQL Serverを使用する場合はWindows OSが必要! っといったことも無くなり、Microsoft SQL Serverがクロスプラットフォームで利用できるようになります。

本ブログではMicrodoft SQL Server 2017 on Linuxに対してDBMotoからテーブルを作成、
レプリケーションを紹介します。

【環境情報】
Source DB:AS/400
Target DB:Microsoft SQL Server 2017 on Linux

【DBMotoサーバとの接続】
まず、DBMoto側で特別必要になる設定はありません。
Microdoft SQL Server 2017 on Linuxへの接続ドライバもDBMotoにバンドルされているため、
Windows版のMicrosoft SQL Serverとの接続と全く同じとなります。

データベース接続設定にて「Microsoft SQL Server」を選択します。

接続プロパティにて、DBMotoで使用するユーザを指定します。

今回は上記のClimbデータベースのdboに対してテーブルを作成し、データのレプリケーションを行います。
これだけでMicrosoft SQL Server 2017 on Linuxへの接続は完了です。

【DBMotoからテーブル作成】
DBMotoからレプリケーションを行う際には、まずターゲットDBに対してテーブルが存在していることが必要となります。
DBMotoにはターゲットテーブルを作成する機能があるため、簡単にターゲットDBに対してテーブル作成を行うことができます。

上記のClimbデータベースに対してテーブルを作成します。

EMPLOYEEという名前のテーブルを作成します。

当然ながら、テーブルにはまだデータは入っていません。
それではDBMotoのデータレプリケーション機能を使用して、データを挿入します。

【レプリケーションジョブの実行】
レプリケーションジョブの実行に関しても、Windows版のMicrosoft SQL Serverと同様に
特別な設定を行うことなくターゲットに対してデータをレプリケーションすることができます。
レプリケーションジョブを実行することで、ターゲットに対してデータを複製できていることがわかります。

このようにしてMicrodoft SQL Server 2017 on Linuxに対しても意識することなくデータのレプリケーションを行うことが可能です。これにより DBMotoを活用して異種データベースとSQL Server on Linux間でのリアルタイム・レプリケーションが確認されました。今回はSource DBにAS/400使用しましたが、Oracleを含む多くの多種データベースをDBMotoはサポートします。

タグ: , , , ,

DB2/400 <=> DB2/400間でのデータベース・シンクロナイゼーション(双方向リアルタイムレプリケーション)についての注意点 [DBMoto]

DBMotoDB2/400(DB2 for IBM i)<=>DB2/400間でのミラーリング(片方向レプリケーション)とシンクロナイゼーション(双方向レプリケーション)の両方をサポートします。

ここでは、DB2/400<=>DB2/400間でのシンクロナイゼーション(双方向レプリケーション)で何も更新を行わなわず、「Idol」状態に戻ってしまう問題について説明します。

【環境】
SourceDB :DB2/400(AS400)
TargetDB :DB2/400(AS400)
InitialRefresh:あり
更新レコード数 :10000件

【状況】
:InitialRefresh完了後、Source及びTargetに更新を行う。
statusに「Mirroring」の表示がされるが、何も更新を行わなわず、「Idol」状態に戻る。以降もシンクロナイゼーションが行われない。

【原因と解決策】
Source(またはTarget)のユーザーが、自分自身に対して更新を行ったために発生。
シンクロナイゼーションモードでは、SourceとTarget間で行われる更新で無限ループ(更新に対する更新)が発生しない様、DBのアクセスユーザーを使用して他との更新の
区別を行っている。そのため更新を行うユーザーを別途用意する必要がある。

参考:DBMotoのAS/400専門サイト

(注)AS/400(またはSystem i)では、そのシステムの中核部分に、RDBMSの機能を統合されていてDB2/400と名付けられた。DB2/400は、現在ではDB2 for IBM iという名称で呼ばれることが多い。

タグ: , , , , , ,

DBMotoで IBM Cloud上の Db2 Warehouse on Cloudに対してテーブルを作成

今回のブログでは、DBMotoのテーブル作成機能を使用して
Db2 Warehouse on Cloudに対してテーブルを作成する方法と注意点を紹介します。

DBMotoからテーブルを作成する場合、DBMotoはソーステーブルの定義を読み取り、
ターゲットテーブルに対して最適な形で作成を行います。
例えば、以下のようなテーブル定義のソーステーブルをターゲットテーブルに作成するとします。

EMPLOYEE_NUMBERは主キーと定義されており、またインデックスも付与されています。
実際にターゲットとなるDb2 Warehouse on Cloudへ発行されるクエリは下記となります。

赤枠内のクエリ内容からも確認できるように、インデックスの作成も実施しようとしています。
しかし、Db2 Warehouse on Cloudは列指向型データベースである仕様上、テーブルに対してインデックスを付与することはできません。

そのため、赤枠内のインデックス作成のクエリを削除し、テーブルを作成する必要があります。

上記画像のようにインデックス作成クエリを削除することで、Db2 Warehouse on Cloudに対してテーブルを作成することができます。

タグ: ,

DBMotoサーバーのホスト名/IPアドレスを変更した場合の対処法

何らかの理由によりDBMotoサーバーのホスト名やIPアドレスを変更した場合、DBMoto側でも設定変更が必要になります。

例)「CLIMB-TEST」⇒「CLIMB-CHANGE」にホスト名を変更した場合

※ホスト名やIPアドレスの変更後はサーバーの再起動を行ってください。

変更後もDBMoto Management Centerに接続された既存のサーバー接続は「CLIMB-TEST」のままとなっています。


そのため、開こうとすると「CLIMB-TEST」に接続できずエラーとなります。


 

■対処法

既存の接続設定を変更することはできないため、新しいホスト名で新規に接続を作成します。

サーバ名はコンソール上に表示される名前なので、任意で入力します。サーバアドレスに変更後の新しいホスト名を入力します。


新しく作成したサーバー接続には、古いサーバー接続で行った設定情報が引き継がれています。


不要であれば、以前のホスト名で作成された接続は削除して問題ありません。

タグ: ,

Syniti Data Replication(旧DBMoto)でIBM Cloud上の DB2 Warehouse on Cloudへの接続

IBM Cloudで使用できる Db2 Warehouse on Cloud(旧dash DB)に対して、データレプリケーションツールである「Syniti Data Replication(旧DBMoto)」を使用した際の設定方法をご紹介します。これにより汎用RDBとDb2 Warehouse on Cloudとのリアルタイムレプリケーションが可能です。

◇Db2 Warehouse on Cloudでの設定

まず、Db2 Warehouse on Cloudへログインします。
ログインにはデフォルトユーザであるbluadminを使用します。

次にDb2 Warehouse on Cloud側でDBMotoで使用するユーザを作成します。

Db2 Warehouse on CloudのGUI上で作成できるユーザには、
権限としてAdministratorとUserのどちらかを割り当てることができます。

DBMotoで使用するユーザには、Administrator権限が必要となります。

DBMotoで使用するユーザを作成後、スキーマを作成します。

これだけでDb2 Warehouse on Cloud上での設定は終わりです。
次に、DBMotoとの接続設定を行います。

◇DBMotoでの接続設定

DBMotoより接続を行う際の設定を紹介します。
Db2 Warehouse on CloudはDB2 LUW互換であるため、
接続の際にIBM DB2 for LUWを指定します。

次に、接続パラメータを指定します。
先ほど作成したdbmotoユーザを用いて接続を行います。
パラメータ指定の際には、Encrypted User And Passwordを指定し、
データベース名をBLUDB、ポートを50000と指定します。

これによりDBMotoとDb2 Warehouse on Cloudを接続することができます。

次回は実際にDBMotoを使用してDb2 Warehouse on Cloudへテーブルを作成する方法、
データのレプリケーションについて紹介します。

タグ: , ,

Oracle Multitenantアーキテクチャに移行する5つの理由 [あるユーザの経験談から]

OracleのMultitenantテクノロジにより、複数のデータベースを単一のコンテナデータベースにプラグインできます。あなたの組織が移行を考慮する必要がありますか。

私の会社の開発およびデータベースをOracle Multitenantアーキテクチャに移行し始めました。マルチテナントは新しいものではなく、Oracle Datebase 12c、バージョン12.1.0.1の最初のリリースで2013年にデビューしました。なぜ私たちはOracle Multitenantアーキテクチャに移行したのか。

以下は、廃止された技術の懸念からより容易な管理まで、そして既存のシステムにされに多くのデータベースを展開するための理由の一覧です。Oracle Multitenantを採用する際に組織に参加することを検討する必要があるかどうかを確認してください。これらのデータベースを1つのコンテナデータベースに入れることができます。マルチメンテナントは、仮想化がデータベースレベルに移行したと考えてください。

Oracleでは、マルチテナントではないアーキテクチャを非難しています。そのとおり、Oracle Multitenantアーキテクチャに移行することを余儀なくされていますが、Multitenant以外の構成が存在しなくなるOracle Datebaseバージョン計画はありません。たとえマルチテナント機能が不要であっても、1つのプラガブルデータベースをコンテナに入れることで、新しいアプローチに慣れ始めることができます。これは、Oracleがシングルテナント構成と呼ぶものです。

つまり、追加コストの技術を支払う必要はありません。プラグイン可能なデータベースが1つしかない場合、Oracle Multitenantは無料です。ただし、完全なマルチテナントアーキテクチャで複数のプラガブルデータベースを実行したい場合は、追加ライセンス料を支払う必要があります。

私たちのVMware仮想化環境は終わりに近づいています。現在、当社の開発およびテストデータベースはVMwareで稼働しており、OracleのみのVMware ESXクラスタのプロセッサでOracle Datebaseのライセンスを取得しています。しかし、2018年9月に一般的なサポートを失うESXi 5.5が稼働していますエンタープライズ内のすべてのESXクラスタのすべてのプロセッサ上でOracle Datebaseのライセンスを取得されることなく、新しいESXi 6.0以上にアップデートすることはできません。Oracleの立場は、仮想マシン(VM)を他のESXクラスタにライブマイグレーションするのは非常に簡単であるため、すべてのライセンスを取得する必要があります。

VMware ESX上でOracleを稼働させることは素晴らしいものでしたが、長期にわたって継続することはできません。私の会社は、別のソリューションを見つける必要があり、私たちのデータベースインフラストラクチャには依然として機敏性があります。物理サーバ上でOracle Multitenantを実行することで、OracleのインフラストラクチャからVMwareを削除することができ、VMwareを保持するだけでなく、俊敏性も向上させます。

データベース管理が容易になります。Oracle Multitenantアーキテクチャは、データベース管理者(DBA)の業務への取り組みを大きく変えます。特定の管理タスクをコンテナまたはプラガブルデータベースレベルで実行する必要があるかどうかを理解する必要があります。ただし、DBAが学習曲線を克服すると、データベースの管理にかかる時間が短縮されます。

私がその会社で働いていた時、数重の非生産データベースを持っていました。7年間で、その数は30以上のデータベースに増加しました。しかし、コンテナデータベースレベルのタスクは、プラグイン可能なデータベースの数にかかわらず、一度だけ実行する必要があります。また、プラグイン可能なデータベースレベルのタスクは、実行するためにすべてのデータベースをループするように簡単にスクリプト化されています。

さらにデータベースを追加できます。私の会社は限られたデータベースで常に苦労してきました。非生産データベースの数が12から30以上に増えたのを見てきました。私たちの経営陣は、アプリケーション開発者にとってより多くのデータベースを提供することを大変喜ばしく思っていますが、VMwareハイパーバイザーホストのリソースに関する問題に縛られています。

別のVMスピンアップするためには、より多くのメモリが必要です。これは、使用可能なRAMの量がボトルネックと思われるためです。Oracle Multitenantアーキテクチャを使用することで、すべてのVMからメモリやその他のシステムリソースのオーバーヘッドを排除できます。これにより、同じ物理ハードウェアを使用して以前よりも多くのデータベースを展開できます。

より迅速にクローンを作成することができます。データベースクローンを作成するためのスクリプトが用意されています。ディスクベースのスナップショットを使用して、ディスクストレージ上に複数テラバイドのデータベースをクローンします。それらのクローンボリュームをVMにマウントしてデータベースを開きます。

現在の設定では、本番データベースの複数のクローンを仮想マシンに作成できます。これらのクローンは、テストデータベースと、生産のコピーである多くの開発データベースを作成するために使用されます。

Oracle Multitenantは、プラガブルデータベースをクローニングできますが、スナップショットクローンを実行する機能も備えています。通常のクローンは、データベース内のすべてのデータファイルを複製します。これは小規模なデータベースに最適ですが、本番データベースのサイズは15TBを超えています。

通常のマルチテナントクローンではデータファイルの複製が必要ですが、スナップショットクローンは複製せずに1分以内に完了します。元のプラグイン可能なデータベースは元のブロックを使用しますが、クローンは変更ブロックのコピーのみを取得します。これにより、非常に高速なクローン作製が可能になると同時に、ディスク領域の要件も削減されます。

 

タグ: , ,

SQL ServerとMySQLリレーショナルデータベースの比較

MySQLとMicrosoft SQL Serverのリレーショナルデータベースには長所と短所があります。SQL ServerとMySQLの機能、コスト、機能などの違いを調べて下さい。

SQL ServerとMySQLは、市場で最も一般的なリレーショナルデータベース管理システムの2つです。MicrosoftのRDBMSは、OracleのMySQLよりも優れた選択肢であり、その逆もあります。

たとえば、Microsoft Windows、UNIX、Linux上で動作するため、MySQLはマルチプラットフォーム環境に最適です。一方、SQL Serverは、深い分析を実行する必要があるWindowsの店舗や、データセンターからAzureクラウドにワークロードを移動する必要がある場合には、より良い選択肢となりそうです。

重要な機能、価格設定、コンプライアンス、その他リレーショナルデータベース管理システム(RDBMS)の考慮事項など、SQL ServerとMySQLの違いを見てみましょう。

Microsoft SQL Serverの機能、価格

MicrosoftのRDBMSの最新バージョンは、6月にリリースされたSQL Server 2016です。Microsoftは、SQL Server 2016の4つのエディションと、Webホスティングプロバイダ向けのWebエディションを提供しています。これらのエディションの2つ、ExpressとDeveloperは無料で利用できます。Express Editionは、最大10GBのデータをサポートできる軽量SQL Serverデータベースで、Developer Editionは開発環境およびテスト環境専用のライセンスを受けています。

その他のSQL Serverのバージョンには、Enterprise、Standard、Webがあります。Enterprise Editionには、ミッションクリティカルなデータベースや高度な分析ワークロードに適したすべての機能が搭載されています。Standard Editionには、小規模な設定に適した機能が限られています。Web Editionは公開Webサイトで使用するためのもので、価格設定をするサードパーティのホスティングサービスプロバイダのみで利用できます。

Microsoftは、Standard EditionとEnterprise EditionをCPUコアごとにライセンスしており、ライセンスは2コアパックで販売されています。SQL Serverがサーバの物理的なOS環境で実行されている場合は、すべてのプロセッサコアのライセンスを購入する必要があります。2コアのSQL Server 2016 Enterprise Editionライセンスは14,256ドルで、2コアのStandard Editionライセンスでは、3,717ドルです。しかし、いずれの技術と同様、実際のライセンス費用は、通常、数量割引などの多くの要因に基づいています。

またMicrosoftは、データベースに接続するユーザまたはデバイスの数を容易に数えることができる場合や、複数のデータベースにアクセスする必要がある場合に使用する、SQL Server Standard Editionの従来のServer + CALライセンスモデルも提供しています。このモデルでは、SQL Serverに接続する各ユーザまたはデバイスに931ドルのサーバライセンスリストとクライアントアクセスライセンス(CAL)が必要です。SQL Server 2016および10クライアントライセンスを含むパックは、Microsoftのオンラインストアで3,189ドルで販売されています。これは、CALあたり約225ドルです。

Oracle MySQLの機能、価格

MySQLは、2010年にSun Microsystemsを買収してこの技術を買収したOracleが所有しています。Sunは、2年前に元の開発者であるMySQL ABを購入しました。バージョン5.7のMySQLデータべースは、商用レベルのRDBMSまたはオープンソースデータベースとして利用できます。MySQL Standard Edition、MySQL Enterprise Edition、およびMySQL Cluster Carrier Grade Edition(CGE)の3つの主要なバリエーションがあります。

また、独立系のソフトウェアベンダーやOEMにしか利用できない組み込みデータベースであるMySQL Classicもあります。 MySQL Community Editionは、GNU一般公衆利用許諾契約書を通じて利用可能なオープンソースのデータベースです。 ただし、管理ツールを含む3つの主要なエディションは、Oracleを通じて商用ライセンスが付与されています。

商用MySQLライセンスはサブスクリプションとして利用でき、価格はMySQL版、通信ソケット数、加入期間によって大きく異なります。 たとえば、MySQL Standard Edition(1〜4ソケット)は1年間2,000ドル、MySQL Enterprise Edition(1〜4ソケット)は1年間5,000ドルのリストです。 MySQL Cluster CGE(5台以上のソケットサーバ)の1年間のサブスクリプションは20,000ドルで販売されます。

SQL ServerとMySQLのパフォーマンスとスケーラビリティ

一度に、MySQLは競合するデータベースよりも能力が劣るという評判を得ました。 しかし、今日では、MySQLは成熟したフル機能のデータベースであり、多くの有名な組織で使用されています。

MySQLは、データベースのスケーラビリティとパフォーマンスを重視しています。 MySQLデータベースは、ほとんどのマルチテラバイトのデータベースに容易に拡張でき、高速トランザクショナルワークロードや1日に最大10億件の膨大な作業負荷を処理するように最適化できます。 MySQLはメモリテーブル、Bツリーインデックス、ハッシュインデックスなどの機能を使用して、非常に高いレベルのパフォーマンスとスケーラビリティを実現します。

他のエンタープライズグレードのデータベースの場合と同様に、MySQLも高可用性のために設計されています。 RDBMSはフェイルオーバークラスタとして構成できますが、高速レプリケーションもサポートしています。 また、MySQLに高可用性オプションを提供する多くのサードパーティベンダーがあります。

マイクロソフトのSQL Serverもまたかなり進化しており、SQL Server 2016は1990年代初めのSQL Serverバージョンとほとんど似ていません。

MySQLと同様に、SQL Serverは高可用性を実現し、最も要求の厳しいワークロードを処理できます。

SQL Server 2016 Editions Chart -- What's New

SQL Server 2016には、データベースのメモリ内OLTP機能を使用するアプリケーションで、パフォーマンスの向上とスケーラビリティの向上を実現するように設計されたメモリ最適化テーブルの拡張されたメモリの最適化テーブルの拡張された高可用性と改善が含まれています。ただし、SQL Serverには、SQL Server 2016よりずっと前のスケーラビリティ、パフォーマンス、および可用性の機能がありました。その結果、Standard Edition 2016の新機能はほとんどは、ビジネスインテリジェンス、セキュリティ、およびクラウドポータビリティなどの機能に焦点を当てています。

たとえば、ストレッチデータベースと呼ばれる機能を使用すると、頻繁にアクセスされないデータをMicrosoft Azureクラウドに格納してコストを削減しながら、必要に応じてクエリを使用できるようにします。 また、Rプログラミング言語のサポートや、HadoopクラスタとAzure BLOBストレージに格納されたデータをユーザーが照会できるようにするツールPolyBaseの完全な統合も含まれています。

SQL Server 2016で導入された注目すべきセキュリティ機能の2つは、行レベルのセキュリティと、常時暗号化されたデータであり、権限のないユーザーが機密データにアクセスすることを防止します。

SQL ServerとMySQLの実装

SQL ServerとMySQLはどちらも、リレーショナルデータベースの標準プログラミング言語であるSQLをサポートしていますが、それぞれ独自の拡張機能を使用しています。

リレーショナルデータベース管理システムを決定する際のもう1つの重要な考慮事項は標準準拠です。 SQL標準はSQL-86標準が導入され、SQL標準が進化し続けている1986年以来存在していました。

MySQLは現在のSQL標準とオープンデータベース接続レベル0〜3.51をサポートしています。さらに、MySQLはANSI、STRICT TRANS TABLES、TRADITIONALなどのさまざまなSQLモードで動作します。 MySQLがいくつかの拡張機能を使ってSQL Server標準を強化していることは注目に値する。そのため、MySQLアプリケーションをMicrosoft SQL Serverまたは競合するSQLデータベースエンジンに移植するには、かなりの労力が必要です。

対照的に、マイクロソフトは、SQL Serverが業界標準に準拠している程度を示していません。 SQL Serverには互換性設定が含まれているため、データベースインスタンスを以前のバージョンのSQL Serverと下位互換性が得られます。マイクロソフトはまた、SQL Serverがデータセンター、クラウド、またはその両方に存在するかどうかにかかわらず、クラウドポータビリティをサポートし、ユーザーに一貫したエクスペリエンスを提供するようにSQL Server 2016を設計しました。

さらに、Microsoftは2017年にLinuxシステム上でSQL Serverを実行するためのサポートを追加する計画をしています。これは、Windowsをはじめて超えるデータベースの動きで、MySQLのマルチプラットフォームの利点を少なくともある程度は鈍らせる可能性があります。

タグ: , ,

Azureのデプロイメントオプションで適切なSQL Serverを選択する方法

AzureクラウドにSQL Serverを展開するには、2つのオプションがあります。 Azure VM上のAzure SQLデータベースとSQL Serverのどちらを選択するのに役立つのかを見てみましょう。

AzureでSQL Serverを実行する組織には、Azure仮想マシンにSQL Serverをインストールする方法とAzure SQLデータベースを使用する方法の2つのオプションがあります。 どちらのアプローチもMicrosoft AzureクラウドでSQL Serverデータベースをホストするために使用できますが、実際の違いはいくつかあります。

Azure SQLデータベースは、SQL Serverユーザー向けのサービス(PaaS)としてのMicrosoftのプラットフォームです。したがって、主にSQL Serverの管理と保守に関連するすべての管理タスクについて、クラウドでデータベースを実行したい組織に適しています。 Microsoftは、クラウドサービスの一部として、パッチ管理などのすべての日常的な保守作業を処理します。

この利便性の代わりにデメリットとして、SQLデータベースはSQL Serverほどの機能が豊富ではないということです。たとえば、マイクロソフトは基盤となるOSやSQL Server自体を公開しません。そのため、データベース管理者はOSの構成を変更することができず、SQL Serverを管理するオプションは非常に限られています。

また、SQLデータベースは主にコマンドラインから管理されるように設計されていることにも注意してください。 Microsoftは2017年初頭にブラウザベースのクエリエディタをリリースしましたが、SQL Server Management Studioを使用してクラウドプラットフォームを管理することはできません。

さらに、Azure SQLデータベースは、サポートできるデータベースの最大サイズに関して制限されています。最近まで、サイズの制限は1 TBでしたが、大規模なデータベースは分割することができました。マイクロソフトは2017年3月にサイズ制限を4 TBに引き上げましたが、これはローカルとクラウドの両方でSQL Serverの最大サイズよりもずっと小さくなっています。

構成とコストの計算

SQLデータベースはサービスとして販売されるため、従来のソフトウェアライセンスは必要ありません。 代わりに、加入者には毎時の定額料金が課金され、地理的に異なる地域のAzureシステムへの送信データ転送には追加料金がかかります。 しかし、定額制の課金はそれほど単純ではありません。

マイクロソフトでは、Basic、Standard、Premium、Premium RSの4種類のサービス階層を提供しています。 正しいパッケージと適切な構成を選択するためには、組織は、ワークロードに必要なストレージ容量、システム可用性、およびパフォーマンスレベルを決定する必要があります。

パフォーマンスは、CPU、メモリ、およびI / O使用量の混合測定値であるデータベーストランザクションユニット(DTU)の数に基づいています。 DTUとストレージのさまざまな組み合わせは、時間単位のさまざまな価格で利用できます。 ユーザーは、複数のデータベースをエラスティックプールにグループ化して、エラスティックDTUまたはeDTUの全体的な測定に価格設定することもできます。

 

 

Azure SQLデータベースにSQL Serverをデプロイする主な用途は2つあります。 まず、従来のSQL Serverの導入をサポートするITスタッフが不足している場合や、データベース管理者(DBA)の管理負担を軽減しようとしている場合に、クラウドサービスの使用を選択する可能性を提示できます。 次に、SQLデータベースは、アプリケーションの開発時間を短縮する必要がある組織にとって最適なプラットフォームです。

Azure仮想マシン上でSQL Serverを実行することは、構内のSQL Serverを実行することに似ています。 他のVMと同様に、OSを含む仮想マシンのコンテンツにフルアクセスできます。 マイクロソフトは、Azureポータルを通じてSQL Server VMイメージを新しいペイ・パー・ミニ・ライセンスまたは既存のオンプレミス・ライセンスの再利用のいずれかで容易に利用できるようにします。 また、独自のライセンスの1つを使用して、VMにSQL Serverをインストールすることもできます。

VMを使うことによるメリット

Azure VM上でSQL Serverを実行することは、データベースソフトウェアとその基盤となるオペレーティングシステムを完全に制御する必要がある組織にとっては最適な選択ですが、VM内でSQL Serverを実行する利点もいくつかあります。

まず、慣れ親しんだ操作で行うことができます。 Azure VM上で動作するSQL Serverインスタンスは、オンプレミスSQL Serverシステムと同様に動作し、動作します。 DBAは、すでに使用していたものと同じ管理ツールを同じ方法で使用することができます。

Azure VMでSQL Serverを実行するもう1つの利点は、Azure VM上でSQL Serverで実行する方法が、Azure SQLデータベースよりも大きなデータベースに対応できることです。 Azure VMには最大64 TBのデータベースストレージをプロビジョニングでき、SQLデータベースの最大4 TBを16倍以上上回ります。

最後に、VM上でSQL Serverを実行することは、クラウドに移行する既存のSQL Serverデータベースを持つ組織にとって、最適な選択です。オンプレミスデータベースをAzure SQLデータベースに移行することは可能ですが、Azure VMで実行されているSQL Serverインスタンスに移行することがほとんどの場合、より簡単に行うことができます。

ご覧のとおり、Azure SQLデータベースとAzure VM上で動作するSQL Serverには基本的な違いがあります。どんな状況においてもどちらのアプローチも他のアプローチより優れていません。単一の組織内であっても、一部のクラウドベースのワークロードはSQL Server上で実行され、他のワークロードはSQLデータベース上で実行されるのが一般的です。使用するプラットフォームは、ブランケット企業の方針ではなく、特定のワークロードの要件に基づいて決定するのが理想的です。

タグ: , ,

任意のデータ型でターゲットテーブル作成[DBMoto]

異種DB間レプリケーションツールDBMotoは、レプリケーション先(ターゲット)へのテーブル作成機能も搭載しています。デフォルトでは、レプリケーション元テーブルのデータ型から、ターゲットDBの種類にあった最適なデータ型を自動的に判別し、テーブルが作成されます。この際、個々のテーブル作成時のGUI画面から、任意のデータ型に手動で変更することも可能です。

ただ、数百とテーブルがある場合、個々のテーブル毎に任意のデータ型を指定するのは手間がかかる作業となってしまいます。デフォルトで指定されるデータ型を変更したい場合は、グローバルスクリプトのCreateTableRuleメソッドをご活用ください。

例えば、レプリケーション元テーブルのデータ型がchar型列である場合に、ターゲットではvarchar型としてテーブル作成を行いたい場合は、下記のような手順で設定します。

1 : 下記スクリプトをグローバルスクリプトにコピー&ペーストし、テーブル作成時のカスタムルールを作成します。

using System;
using System.Data;
using System.Collections;
using System.Collections.Generic; 
using DBMotoPublic;
using DBMotoScript;

namespace DBRS
{
    public class GlobalScript : IGlobalScript
    {
    }

    public class MappingRule : IMappingRule
    {
    }

    public class CreateTableRule : ICreateTableRule
    {
     [CreateTableRuleAttribute("Create Table Data Convert", 
   "Convert columns type from char to varchar")] 
   public bool MyCustomAuditTable (List<ColumnClass> aTargetFields)
     {          
        foreach(ColumnClass colClass in aTargetFields)
        {
            if (colClass.TypeName.ToLower() == "char")
                colClass.TypeName = "varchar";
        }          
        return true;
     }     
    } 

    public class GlobalEvents : IGlobalEvents
    {
    }

}

2: ターゲットDBの接続プロパティを開き、[テーブルカスタムルールを作成]の設定から、作成したカスタムルールを指定します。

3: char型のテーブルをターゲットDBに作成しようとすると、デフォルトでvarchar型として指定されるようになります。

コメントする -->

保護中: DBMoto 9.0.8.40 リリースノート

このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。

コメントを読むにはパスワードを入力してください。 -->

初期同期(リフレッシュ)をもっと柔軟にリフレッシュフィルタ機能[DBMoto]

DBMotoでは初回のレプリケーション時や任意のタイミングで全件転送を行うリフレッシュを実施可能です。この全件転送の主な流れとしては、まず、ターゲットテーブルをきれいにするため、ターゲットのテーブルデータを全て削除(TruncateやDeleteなど)し、その後ソーステーブルのデータを全て選択(Select)、ターゲットテーブルに全件挿入(Bulk InsertまたはシングルInsert)するというものです。
https://www.climb.co.jp/soft/dbmoto/outline/mode.html#mode01

これにより、完全にソース/ターゲットテーブルのデータを一致させることができますが、テーブルのデータ量によって長時間かかるケースがあります。

これを避けるために、本当に同期が必要なデータのみをリフレッシュしたい、また、障害等により、データの不一致が発生し、その不一致のデータ範囲が特定できている場合などに全データをリフレッシュで同期させるのではなく、特定範囲のみのデータをリフレッシュで同期させたいという要望をいただくケースがございます。

このような要望を解決する機能がリフレッシュフィルタ機能です。設定としては下記のようにソースリフレッシュフィルタとターゲットリフレッシュフィルタが存在します。

  • ソースリフレッシュフィルタ:②で取得するデータをWhere句での条件指定と同様に制限できます。
  • ターゲットリフレッシュフィルタ:①で削除するデータをWhere句での条件指定と同様に制限できます。

初期リフレッシュで一部データのみを同期させたいような場合には、ソースリフレッシュフィルタのみで問題ありません(ターゲットテーブルにデータが存在しない状態)。既にレプリケーション済みで改めてリフレッシュを行う場合には③の挿入で重複しないようにソース/ターゲット両方で同様の条件を指定する必要があります。このようにリフレッシュフィルタを用いることでより柔軟にDBMotoをご利用いただけます。

コメントする -->

SQL Server on Linuxの可用性について ②

前回の投稿では、SQL Server on Linuxの基本的な可用性について紹介しました。
本記事ではそれ以外の可用性機能について紹介します。

◆SQL Server on Linuxのフェイルオーバクラスタリング

Windows版と同様に、SQL Server on Linuxのフェイルオーバクラスタは、共有ストレージに接続された複数のサーバで構成されています。サーバはクラスタノードと呼ばます。
Windows版のSQL Serverのフェイルオーバクラスタリングインスタンスと同様に、SQL Server on Linuxクラスタリングは、インスタンスレベルでの保護、自動および手動のフェイルオーバ、アプリケーションやクライアントの透過的なフェイルオーバ、数秒から数分のPTOをサポートします。

SQL Server on Linuxでフェイルオーバクラスタリングを行う場合は、Windows版とは違い、ネイティブのLinux Pacemaker high availabilityテクノロジを使用します。
すべてのクラスタノードは、ストレージリソースへのアクティブな接続を必要としており、Pacemakerが障害を検出すると、クラスタリングコンポーネントはSQL インスタンスを別のノードへ移動させます。
イメージとしては、下記のような図となります。

◆AlwaysOn可用性グループ

Windows版のSQL Serverと同様に、SQL Server on Linuxの可用性レベルはAlwaysOn可用性グループによって提供されます。

SQL Server on LinuxにてサポートされているAlwaysOn可用性グループは以下となります。

  • 最大8つのセカンダリレプリカの保護
  • 複数データベースの保護
  • 最大3つの同期レプリカ
  • 同期および非同期のセカンダリレプリカの混合
  • 手動または自動でのフェイルオーバ
  • 読み取り専用のセカンダリ提供
  • 読み取り専用ルーティング

Linux上の可用性グループには、2つの構成タイプがあります。Pacemalerを使用してビジネス継続性を提供する高可用性構成を作成するか、クラスタマネージャーを使用せずに読み取りスケールアウト可用性グループを作成できます。読み取りスケールアウトは、パフォーマンスのスケールアウトのための読み取り専用レプリカのみを提供します。

高可用性とデータ保護を提供する可用性グループ構成には、3つの同期レプリカが必要です。Windows Serverフェールオーバークラスタが存在しない場合、可用性グループの構成は、参加するSQL Serverインスタンスのマスターデータベースに格納されます。高可用性とデータ保護を提供するには、少なくとも3つの同期レプリカが必要です。

2つの同期レプリカを持つ可用性グループはデータ保護を提供できますが、この構成では自動高可用性を提供できません。プライマリレプリカが停止している場合、可用性グループは自動的にフェイルオーバーします。

ただし、プライマリレプリカがリカバリされるまで、アプリケーションは自動的に可用性グループに接続できません。WindowsとLinuxの両方のレプリカを含む可用性グループを混在させることができますが、Microsoftはこれをデータ移行にのみ推奨します。

SQL Server on Linuxは、企業がリレーショナルデータベースアプリケーションに必要とするエンタープライズレベルのデータ保護および可用性機能を提供します。ただし、LinuxのSQL Serverはフェールオーバークラスタリング、可用性グループ、およびログ配布をサポートしていますが、データベースミラーリングはサポートしていません。データベースのミラーリングはWindows版のSQL Server 2017でもサポートされていますが、将来的に削除される予定の償却された機能です。

タグ: , ,

SQL Server on Linuxの可用性について ①

先日発表されたSQL Server 2017の中に、Linux版のSQL Serverがあります。
しかし、Windows版とLinux版では可用性とフェイルオーバの実行方法にいくつかの制限と変更があります。

SQL Server on Linuxを導入することを検討している企業は、Linux版とWindows版の機能がどれだけ異なっているか理解する必要があります。今回リリースされる最初のSQL Server on Linuxでは、オンライントランザクション処理、データベースアプリケーション、および基本的なデータウェアハウスをサポートするリレーショナルデータベースエンジンで構成されています。
そのため、Analysis Services、R Services、Reporting Servicesなどの他のサブシステムは含まれていません。
Red Hat Enterprise Linux 7.3、SUSE Enterprise Linux Server 12 SP2、MacOS、Ubuntu 16.04 LTSおよびDocker Engine 1.8以上でサポートされています。

SQL Server on Linuxに関する最大の関心事の一つに、サポートされる高可用性オプションがあります。MicrosoftはSQL Server on Linuxにいくつかの可用性と障害時の復旧オプションを提供します。

◆基本的なSQL Serverの可用性機能

基本的な機能として、SQL Server on Linuxではバックアップと復元、仮想マシンのフェイルオーバ、およびログのエクスポートをサポートしています。これは、Express、Standard、Enterpriseエディションを含むすべてのSQL Serverのエディションで使用できます。

バックアップと復元は、最も基本的なSQL Serverのデータと障害回復機能です。
SQL Server on Linuxではデータベースのフルバックアップ、差分バックアップ、およびトランザクションログバックアップを含む基本的なSQL Serverのバックアップと復元をサポートしています。

SQL Server on Linuxのバックアップと復元は、リモートで接続しているWindowsマシンより、Transact-SQL(T-SQL)またはSQL Management Studioを使用して利用できます。Windows上のデータベースをSQL Server on Linuxへ移行するためにも使用でき、Windows上のSQL Serverをバックアップし、SQL Server on Linuxへとリストアすることもできます。また、逆も同様です。バックアップ形式は同じであり、SQL Server 2014以降で動作するデータベースと互換性があります。

Hyper-VレプリカまたはVMware HA機能を使用して、シンプルなVMフェイルオーバオプションを実装することもできます。これによりホスト、ゲスト、OSの障害からの回復に役立ちます。また、ホストインスタンスにパッチを適用する前に手動でフェイルオーバできるようにすることで、ソフトウェアのアップグレードやパッチ適用などの計画されたダウンタイムを保護することができます。

SQL Serverのログエクスポートは、プライマリサーバのデータベースが1つまたは複数のセカンダリサーバへレプリケーションされる高可用性および障害復旧機能です。プライマリデータベースのバックアップはセカンダリサーバにリストアされます。プライマリサーバは定期的にトランザクションログのバックアップを作成し、セカンダリサーバに転送し、復元します。

SQL Server on LinuxはCIFSやSambaを使用して、トランザクションログのバックアップが保存されているネットワーク共有を設定ます。SQL Server on Linux Agentは定期的にトランザクションログのバックアップをセカンダリサーバに転送するストアドプロシージャを実行するために使用されます。
Windowsと同じくデータベースの復旧は手動で実施します。

タグ: , , ,

スクリプトを使用してSQL Serverにデータベースを作成する方法

SQL Serverデータベースは手動で作成できますが、スクリプトデータベースのセットアップ方法を知ることは貴重です。ここでは、データベース作成スクリプトの実行に必要な手順を示します。

SQL Serverデータベースは手動で作成することもできますが、スクリプトによるデータベース作成を実行して、プロセスをより簡単に反復可能にすることも可能です。実際、少なくとも一部のMicrosoftサーバ製品では、セットアッププロセスの一環としてこの背後にあるこの技術を使用しています。

MicrosoftのPowerShellスクリプト言語とエンジンを使わなくても、SQL Serverのデータベーススクリプトを作成するのは本当に簡単です。以下の図1に、メモ帳で作成されたSQL Serverデータベースを作成するためのサンプルスクリプトを示します。

3つのコード行のうちの最初の行は、現在作成しているデータベースが現在存在するかどうかを調べます。この場合、スクリプトはmasterデータベースの下にDemoという名前にデータベースを作成します。また、分かりやすく簡単なこともありません。

最後のコード行は、これが命令ブロックの終わりであり、スクリプトを実行してデータベースを作成すべきことをSQLに伝えます。イメージを見ると、スクリプトのファイル名には.SQLがスクリプトを認識するために必要です。

Database named Demo

図1. このスクリプトは、Demoという名前のデータベースを作成します。

SQL Serverデータベース作成スクリプトを使用するには、SQL Server Management Studio(SSMS)を開く必要があります。この記事では、メインインストールルーチンにSSMSを含まないSQL Server 2016を使用しています。その結果、MicrosoftのWebサイトからSSMSを個別にダウンロードする必要があります。

Database within SSMS

図2. SSMS内にデータベース作成スクリプトが表示されます。

さらに、新しいファイル行がツールバーのOpen Fileアイコンの下に追加されます。図2のように、ツールバーのドロップダウンメニューがMasterに設定されていることを確認します。これは、データベース作成スクリプトがmasterデータベースに対して実行されることを示します。ここで、Executeボタンをクリックしてスクリプトを実行します。

実行が完了すると、スクリプトが正常に実行されたことを示す図3の下部にあるようなメッセージが表示されます。また、コンソールツリーに新しいデータベースが表示されていることも確認して下さい。このスクリプトは、Demoという名前のデータベースを作成するように設計されており、新しく作成されたDemoデータベースイメージ内に表示されることを覚えておいてください。

Creating Demo database

図3. デモデータベースが作成されました。

ここで、作成したばかりのデータベース内にテーブルの作成をスクリプト化する方法を見てみましょう。以下の図4に、使用できるサンプルコードを示します。

コードはMyTableという名前のテーブルの存在を確認することから始まります。テーブルがまだ存在しない場合は作成されます。新しいテーブルには、Idという名前の主キーと、別の名前と値の列の3つの列が含まれます。列の定義はスクリプト内でコンマで区切られています。

MyTable database

図4. このスクリプトは、MyTableという名前のデータベーステーブルを作成します。

私たちは、データベース作成スクリプトと同じテクニックを使用してスクリプトを実行できますが、主な違いが1つあります。ドロップダウンメニューからマスターを選択する代わりに、デモを選択してでもデータベース内にテーブルを作成する必要があります。これは図5のようになります。

Script against Demo

図5. このスクリプトはデモデータベースに対して実行されています。

スクリプトが実行されると、新しいテーブルが作成されます。新しいテーブルが表示される前に、データベースを右クリックし、Refreshコマンドを選択してデータベースを更新する必要があります。図6は、新しい表とその列を示しています。

New database table

図6. スクリプトは、3つの列を持つ新しいデータベーステーブルを作成しました。

すべての正直なところ、データベースとそのテーブルを手動で作成するほうが早いでしょう。ただし、SQL Serverデータベース作成スクリプトを使用してテーブル1を作成することにより、データベースとテーブルの新しいバージョンを、必要に応じて、一貫した方法で追加することが可能になりました。

タグ: , ,

DBMotoからIBM dashDBへの接続設定

IBM社が提供するPaaS「Bluemix」向けのサービスとしてクラウドでのデータウェアハウジングと分析サービス「dashDB」が提供がされています。

DBMotoでdashDBをレプリケーション・データベースをして取り扱うことができます。Ritmo DB2ドライバを使用してDBMotoからdashDBへの接続を設定します。設定終了後にdashDBはターゲット(複製先)データベースとしてミラーリング・モードで使用することができます。

1) DBMotoのManagement Centerでターゲットを右クリックし、新規接続を選択します。

dashDB1

ここでDatabaseはdashDBに替わって「IBM DB2 for LUW」、Providerには「HiT Software .NetDriver(Ritmo/DB2)」を選択します。

dashDB2

2) 次に「Encrypted Password」を選択します。

dashDB3

3) 接続情報入力後に「テスト」ボタンをクリックし、接続が完了したことを確認します。

dashDB4

これで接続設定が終了したことを確認できます。これによりDBMotoを利用してdashDBと他のデータベース間でのレプリケーションが可能になります。

タグ: , ,