このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2015/10/16/sql-anywhere-17--a-new-maxconnections-database-option

これまでは、個々のユーザーがサーバーに接続できる接続数は、ライセンスで制限されていました。

また、ユーザー数が無制限である以前の Chip ベースのライセンスモデルでは、デフォルトの接続数は32,766に設定されていましたが、サーバー側の -gm オプションを使用することで変更することができました。

また、サーバープロパティ() 関数を使用することで、 MaxConnections プロパティを得る、つまりサーバーに許諾されている同時接続の最大数を返すことができました。

SQL Anywhere 17 では、新たに「max_connections」のパブリック データベースオプションを設定することで、個々のデータベースに対する同時接続の総数を制限することができるようになりました。これにより、SQL Anywhere のデータベース同時接続の総数を特定の数に設定し制限することができます。

このmax_connections オプションは、データベース内でこれをpersistすることなく制限設定できるよう、テンポラリーオプションとして設定してすることもできます。

しかしながら、このデータベースオプションは、サーバー側の最大同時接続数の設定をオーバーライドする目的では使用できない点に注意してください。‘MaxConnections’ のサーバープロパティ設定よりも大きな数を設定しようとしてこの max_connections データベースオプションを使用しても、意味はありません。

1つのデータベースに対して許容される同時接続総数は、以下のルールで決まります。

• サーバー接続の総数 (SELECT property('MaxConnections') FROM DUMMY) は、超えられない (DROP ANY CONNECTION 特権による1ユーザーを除いて)。
  • SQLERR_TOO_MANY_CONNECTIONS のエラーが返される
• データベース接続の総数 (SELECT db_property('MaxConnections') FROM DUMMY) は、超えられない (DROP ANY CONNECTION 特権による1ユーザーを除いて)。
  • SQLERR_TOO_MANY_DB_CONNECTIONS のエラーが返される
• ユーザー接続制限の総数は超えられない

また、新たなレベルのデータベースプロパティである ‘MaxConnections’ を使うことで、上に定義したような、そのデータベースに対して設定できる最大接続数を反映することができます。

データベース接続制限にカウントされるのは、「ライセンスされた」接続のみです。イベント、ミラーリング、モニタリング、などの内部の接続は、カウントされません。しかしながら、HTTP接続はカウントに含まれます。

例えば、パーソナルサーバー（または、10接続にライセンスが制限されている場合）では、以下のとおりです。

max_connections を20に設定すると、以下のようになります。

なぜならば、パーソナルサーバーの最大接続数は10に決められているため、max_connections オプションでこれ以上の数を設定しようとしても、反映されません。

しかしながら、max_connections の値を5に設定するのであれば、以下のようになります。

これで、現在このデータベースの接続は5に制限されています。残りの接続数(5)は、同じサーバー上で稼働する他のデータベースで使用可能です。

備考: 接続制限に達してしまった場合でも、 DROP ANY CONNECTION 権限を持つ単一のユーザーがデータベースに接続できるようプロビジョンがサーバー内にビルドされています。これにより、管理者は必要に応じて接続し、1以上の接続を除くことができます。 (例：他の全ての接続がデッドロック状態になってしまった場合、リソースを使いすぎている場合、etc. …)

既存のデータベース (version 16 とそれ以前のもの) では、この機能は使用できません。max_connections データベースオプションをこれらのデータベースで設定しても、設定は無視され、設定前と同様の動きを継続します。また、ALTER DATABASE UPGRADE を使用してデータベースをアップグレードしようとしてmax_connections オプションを設定しても、アップグレードは SQLERR_UPGRADE_CONFLICTING_OPTION のエラーになりできません。 max_connections オプションは、アップグレードが継続可能であるようにそれ以前に除く必要があります。

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

https://scn.sap.com/community/sql-anywhere/blog/2015/09/25/sql-anywhere-17--in-memory-database-validation

バックアップとリカバリプランの一環として、リカバリプロセスのテストを定期的に行うとともに、バックアップに成功した後にバックアップデータベースをバリデーションするのがベストプラクティスであると考えられています。本番データベースが有効かどうか、バックアップがクリーンか、必要な時にリカバリ可能かどうか確認するにはこれがベストな方法です。

しかし、残念ながら、サーバーのバックアップデータベースを起動するということは、そのバックアップデータベースに関連したログファイルのオフセットの予期したスタートに先行して、（少なくとも）チェックポイントが発生します。

これはつまり、そのバックアップデータベースをリカバリに使用した場合には、本番データベースからログファイルをそれに適用することはできないことを意味します。なぜならば予期したログオフセットはもはやマッチしないからです。

バックアップが有効であり、さらにそれがまだリカバリに使用できることを確認するには、バックアップデータベースを「リードオンリー」モード（サーバー –r オプションまたは START DATABASE 文の FOR READ ONLY 句 ）で起動し、そのデータベース/ログに何の変更もないことを確認する必要があります。

多くの場合はうまく機能しますが、全てうまくいくとは限りません。もしバックアップを開始し、データベース内にオープンなトランザクションがある場合には（よくあることですが）、そのバックアップデータベースはそれが開始される時にリカバリを経る必要があります（これらのトランザクションを完了するか、またはロールバックし、ACID 準拠のデータベースを確認します）。

これはつまり、「リードオンリー」モードをバリデーションには使用できないということを意味します。

この場合には、バックアップデータベースのコピーを作成してスタートし、データベースをリカバリさせ、それからバリデーションを行います。明らかに、これではバックアッププランに対して時間とディスクスペースの両方の面でオーバーヘッドを大幅に増加させてしまいます。

バージョン17では、「in-memory validation」または IMVと呼ぶ新しいインメモリーモードでこれに対応しました。これは、データベースとログファイルのコピーを別に作成しなくともバックアップのバリデーションができるようにするものです。

別途ライセンスが必要な（Editionによっては含まれていない）SQL Anywhere のその他のインメモリーモード (in-memory checkpoint-only モード (-im c) や in-memory never-write モード (-im nw ))とは異なり、この in-memory validation モードは全ての SQL Anywhere のバージョンに含まれています。

つまりこれは、別途ライセンスされるコンポーネントでは ありません（Editionによっては含まれていないということはありません）。

In-memory validation モードは、サーバーのコマンドライン上で、"-im validation" スイッチ (あるいは短縮して "-im v" ) と指定することで有効になります。

dbsrv17.exe –im v foo.db

このサーバー in-memory validation モードでは、以下のような動作になります。

• データベースファイルとログファイルはディスク上では決して修正されません。
• 全ての修正は、データベースサーバーのキャッシュで維持されます。そのため、チェックポイントログ、redo ログ、そして/または undo ログが大きな数のデータベースページを修正する場合には、サーバーのキャッシュ（例：メモリー）がなくなる可能性があります。
• サーバーは、temp ファイルを作成＆使用して、可能な場合にはキャッシュプレッシャーを緩和します。
• インメモリーの修正 (DML, DDL, etc) は、リカバリタスクでのみ変更可能です(つまり、チェックポイントログ、redo ログ（1または複数)、そしてundo ログ（1または複数）を適用するため）。
• クライアント接続、ユーザー定義のイベント、etc のような全てのノンリカバリのオペレーションは、リードオンリーです（サーバーのリードオンリー(-r) モードと似ている）。
• データベースは、-a、-ad、または -f のフラグが指定されている場合には、リカバリ後にシャットダウンしません。
• サーバーは "-r" (read-only) コマンドラインオプション（1または複数）を無視し、START DATABASE 文のFOR READ ONLY 句は無視します。
• IMV モードで稼働しているデータベースのバックアップは、オリジナルと一致するバックアップ、つまり IMV サーバー上でスタートされた修正されていないデータベースファイルを生成します。

DBValid/DBValidate()へのアップデート

サーバーの動作変更に追加して、dbvalid コマンドラインツールでは、新たに "-im <mode>" スイッチをサポートし、サーバーの in-memory モードをコントロールできるようにしました。しかし、これは autostart するサーバーに限られます。Valid モードには、none、v、c、nw が含まれます。デフォルトのモードは v です。

デフォルトの 'v' モードを含む 'none' 以外のモードが使用された場合には、dbvalid は、提供された "-im <mode>" スイッチを StartLine 接続パラメーターにアペンドします。そうでない場合には、StartLine は "dbeng16 -im <mode>" に設定されます。StartLine にすでに "-im <mode>" コマンドラインスイッチが含まれる場合には、サーバーは最初のものを尊重します (つまり、dbvalid でアペンドされたものではなく接続ストリングからのもの）。–im 'none' が指定されている場合には、StartLine は設定も修正もされません。

dbtools ライブラリ DBValidate(…) メソッドもまた、新しいインメモリーモードオプションをサポートするためにアップデートされました。

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2015/09/09/sql-anywhere-17--enhanced-auditing

監査データベースインタラクションを使用すると、データベース内で誰がいつ何を行ったのかということを確認することができます。これは、格納されているデータが機密的なものの場合（例：給料情報や社外秘のレシピなど）で、ある特定の期間に誰がそのデータにアクセスしたかをトラッキングする必要があるようなシナリオでとても有効です。また、不適切にデータが変更/削除された時に、何が起こったのか判別する場合や、違反を減らそうとする場合にも便利です。SQL Anywhere の監査機能では (有効になっている場合には) 、以下に挙げるようなデータベースに対して行われたアクティビティを全てトラッキングします。

• ログイン試行情報 (そのユーザーがログインに成功したのかあるいは失敗したのかなどの情報）
• 全イベントのタイムスタンプ
• パーミッションチェック (成功と失敗のオブジェクト情報など）
• システム権限を必要とする全アクション
• sa_audit_string(…) ストアドプロシージャー経由で監査ログに追加されたカスタム監査文字列

厳密に何を監査するかは、sa_enable_auditing_type(…) システムプロシージャーを使用することによって管理することができます。

また、ログイン時に“conn_auditing” オプションを設定することによって、監査を有効または無効にすることができます。

version 16 では全ての監査情報が、トランザクションログ内に格納されます。

Version 17 では、新しいオプションである AUDIT_LOG が追加されました。これは、監査情報に1以上の異なるターゲットを指定することができます。潜在的なターゲットとしては、以下のようなものがあります。

• TRANSLOG (デフォルト) – version 16と同様、監査データはトランザクションログ内に格納されます。
• SYSLOG – 監査情報は、システムイベントトレーシングログに記録されます。(例：WindowsにおけるWindows イベントログ、Linux/Unixにおけるsyslog)
• FILE – 監査情報は、サーバー ETD (Event Trace Data) フォーマットを使用して、指定されたファイルに記録されます（サーバーはこれに対しての書き込みアクセスが必要）。

様々な理由に合わせて、異なるターゲットを選択して使用することができます。

例えば、そのデータベースにトランザクションログを使用したくない場合、OSログの調査に既存のツールを使用している場合、データベースオペレーションに関する監査情報を、単に実際のオペレーションの実行記録から分けたい場合などです。

audit_log オプションの設定には、SET ANY SECURITY OPTION 権限が必要です。監査ターゲットに問題がある場合には、他のターゲットが使用できない時には、トランザクションログを使用するようにリバートし、サーバーはベストを尽くして監査を継続します。

以下は、audit_log オプションの使用方法と、その結果ログの例です。

最初に、適切なセキュリティー管理権限を持ったユーザーとして接続し、監査を有効にします。audit_log optionを設定して、ファイルに監査情報の詳細を記録します。

sa_audit_string()ストアドプロシージャーを使用すれば、いつでも、カスタムメッセージを監査ログに記録することができます。

次に、新たに作成した testuser として接続します。これは、パーミッションエラーで失敗します。

オリジナルの接続に戻って、監査を無効にします。監査ログに相当のメッセージを記録します。

上記が完了したら、指定したディレクトリに監査ファイルが生成されています。デフォルトでは、 “_0.etd” です。

以下を実行します。

dbmanageetd –o auditlog.out _0.etd

これによって、“auditlog.out” ファイルが作成されます。以下に似たセクションが含まれています。

カスタムの監査文字列を確認することができます。テストをブックマークして使用することができます。

[2015-09-08T10:28:10.254-04:00] SYS_Audit_String  text=[Auditing has begun.] connid=25 username=[DBA] recnum=17

次に、DBISQLによって作成されたコールに関連した様々なパーミッションチェックを確認することができます。

[2015-09-08T10:28:10.301-04:00] SYS_Audit_PermCheck  success=1 perm_type=[Execute] detail1=[dbo.sa_locks] detail2=[NULL] connid=25 username=[DBA] recnum=18

[2015-09-08T10:28:10.301-04:00] SYS_Audit_PermCheck  success=1 perm_type=[Execute] detail1=[dbo.sa_locks] detail2=[NULL] connid=25 username=[DBA] recnum=19

[2015-09-08T10:28:10.301-04:00] SYS_Audit_PermCheck  success=1 perm_type=[MONITOR] detail1=[NULL] detail2=[NULL] connid=25 username=[DBA] recnum=20

次に、testuser 接続から DBISQL によって作成されたコールに関連する様々なパーミッションチェックを確認することができます。

[2015-09-08T10:28:12.064-04:00] SYS_Audit_PermCheck  success=1 perm_type=[Execute] detail1=[dbo.sa_locks] detail2=[NULL] connid=8 username=[testuser] recnum=21

[2015-09-08T10:28:12.064-04:00] SYS_Audit_PermCheck  success=0 perm_type=[MONITOR] detail1=[NULL] detail2=[NULL] connid=8 username=[testuser] recnum=22

[2015-09-08T10:28:12.064-04:00] SYS_Audit_PermCheck  success=1 perm_type=[Execute] detail1=[dbo.sa_locks] detail2=[NULL] connid=8 username=[testuser] recnum=23

[2015-09-08T10:28:12.064-04:00] SYS_Audit_PermCheck  success=0 perm_type=[MONITOR] detail1=[NULL] detail2=[NULL] connid=8 username=[testuser] recnum=24

次に、(監査記録内で、 “success=0”で示された) select 文でパーミッションの失敗が確認できます。

[2015-09-08T10:28:13.094-04:00] SYS_Audit_PermCheck  success=0 perm_type=[Select] detail1=[GROUPO.Employees] detail2=[NULL] connid=8 username=[testuser] recnum=25

[2015-09-08T10:28:13.094-04:00] SYS_Audit_PermCheck  success=0 perm_type=[Select] detail1=[GROUPO.Employees] detail2=[***] connid=8 username=[testuser] recnum=26

そして最後に、監査の最後にカスタムメッセージを確認することができます。

[2015-09-08T10:28:19.256-04:00] SYS_Audit_PermCheck  success=1 perm_type=[Execute] detail1=[dbo.sa_audit_string] detail2=[NULL] connid=25 username=[DBA] recnum=35

[2015-09-08T10:28:19.256-04:00] SYS_Audit_PermCheck  success=1 perm_type=[MANAGE AUDITING] detail1=[NULL] detail2=[NULL] connid=25 username=[DBA] recnum=36

[2015-09-08T10:28:19.256-04:00] SYS_Audit_String  text=[Auditing is ending.] connid=25 username=[DBA] recnum=37

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/docs/DOC-65219

以下よりリンクされるページ（英語ページ）の表では、SQL Anywhere でサポートしている各プラットフォームにおいて利用可能なコンポーネントをリストアップしています。

いくつかの例外として、全てのサポートプラットフォームで利用可能なコンポーネントはリストアップしていません。読みやすいよう、OSベンダー名およびプロセッサーアーキテクチャによってグループ分けしています。

特定のOSのサポートについては、 SAP SQL Anywhere サポートOS および エンジニアリングサポート状況をご参照ください。

1. データベース
   • SQL Anywhere
   • Ultra Light
2. データ同期、メッセージング、レプリケーション
   • Mobile Link
   • Mobile Link 統合データベース
   • SQL Remote for SQL Anywhere
3. 管理ツール
4. マニュアル

注意： 英語ページにおける「X」は、「〇(サポート)」を意味していますのでご注意ください。

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2015/09/15/sql-anywhere-17--enhanced-password-protection

SQL Anywhere 17 では、セキュリティをより強化するためにパスワードの管理や、様々なツール、ユーティリティからのアクセスに関連する変更が複数実装されました。

それらの変更について、以下に簡単に説明します。

システムテーブルのパスワードハッシュへのダイレクトアクセス

データベースセキュリティのベストプラクティスとして、データベース内のパスワードハッシュ値へのアクセスには2種の異なるアクター --- 管理者（SELECT ANY TABLE 権限を持つユーザー）とセキュリティオフィサー（ACCESS  USER PASSWORD 管理権限を持つユーザー）--- が必要です。

version 17 では、データベース内に格納されるパスワードの保護を強化するため、サーバーは、クエリー内のパスワードのハッシュは返さなくなりました。下のビューでは、パスワードが含まれるカラムは、どのユーザーのものも「***」 に置き換えられています。

• SYSUSER
• SYSUSERPERM
• SYSUSERAUTH
• SYSEXTERNLOGIN
• SYSLDAPSERVER
• SYSSYNC2

また、下のシンクロナイゼーションが関連するビューは、ISYSSYNC テーブルではなく、SYSSYNC2 ビューから選択します。その結果「‘***」で置き換えられる機密的なカラムが存在します。

• SYSSYNCS
• SYSSYNCUSERS
• SYSSYNCPUBLICATIONDEFAULTS
• SYSSYNCSUBSCRIPTIONS
• SYSSYNCPROFILE

version 17 では、データベース内に格納されている実際のパスワードハッシュとパスワード値へのアクセスには、2つの権限が必要になります。SELECT ANY TABLE 権限と新しい ACCESS USER PASSWORD 権限です。「ACCESS USER PASSWORD」権限は、パスワードハッシュを含むビュー（下のリスト参照）へのアクセスを一人のユーザーに対して許可し、データベースの比較、アンロード、抽出などのパスワードへのアクセスを含むオペレーションの実行を許可します。

機密的な情報やパスワードをレポートする下のビューへアクセスするには、SELECT ANY TABLE にともなう ACCESS USER PASSWORD の権限が必要です。

• SYSSYNC
• SYSSYNCPROFILE
• SYSUSERPASSWORD
• SYSLDAPSERVERPASSWORD
• SYSEXTERNUSERPASSWORD

これらの変更の結果、ユーザーのコピー/ペースト オプション、外部ログイン、LDAP サーバーとシンクロナイゼーションの定義オプションなどと同様にに、Sybase Central のスキーマ diff utility に動作変更があることに気づかれるかもしれません。

DBUnload/DBXTRACT の変更

また、デフォルトでは、DBUnload または DBXtract ではパスワードはアンロードされなくなりました。

DBUnload は、同じ（またはほんの少し変更した）スキーマとデータでデータベースを再作成する目的で、結果をデータベースにリロードしなければならない場合にのみ、パスワードハッシュのアンロードを試みます。

パスワードなしでデータベースがアンロードされた場合には、GRANT CONNECT、CREATE EXTERNLOGIN、CREATE LDAP SERVER のステートメント文には、指定された IDENTIFIED BY 句を持ちません。デフォルトDB ユーザーの GRANT CONNECT 文が、（デフォルトパスワードで）追加されます。

DBUnload と DBXtract ユーティリティは、–up オプションが指定された場合に、パスワードをアンロードします。そして、アンロード/抽出を実行しているユーザーは、適切な権限を持ちます（下参照）。

リロードオプション (-ac, -an, -aob, etc…) のいずれかを使用する場合には、-up オプションが示唆されます。

DBUNLOAD と –no オプション (データベーススキーマ比較を実行する場合に使用される) は、パスワードを含むパスワードハッシュと値をアンロードすることは決してありません。

アンロードと新しいデータベース (-an, -ao, -aob) へのリロードには、SELECT ANY TABLE, SERVER OPERATOR、そして ACCESS USER PASSWORD システム権限が必要になります。アンロードと既存のデータベース (-ac) へのリロードには、SERVER OPERATOR システム権限は必要ありません。再構築を実行しているユーザーのみ、 SELECT ANY TABLE と ACCESS USER PASSWORD の両方をその再構築プロセスの間のみ一時的に与えることをお奨めします。コンパチビリティDBA ユーザーは、上のオペレーションに必要なロールを全て持っていることに注意してください。

EncryptedPassword 接続パラメーターの改善

セキュリティの観点では、DSN 定義 (または、クライアントコンピューターのどこにも) の一部としてパスワードを決して保存しないことがベストプラクティスですが、多くのデベロッパーはアプリケーションの配布と管理を容易にするため、ベストプラクティスにはしたがっていないようです。

これに対し、SQL Anywhere では、(例えばDSN定義内の）ローカルマシン上のプレーンテキストパスワードをユーザーが見てしまわないように、パスワード（PWD）接続パスワードの代替として使用することができる EncryptedPassword (ENP: 暗号化したパスワード) 接続パラメーターを提供しています。

ENP 接続パラメーターの目的は、データベースの認証に使用されている実際のパスワードをカモフラージュすることです。しかしながら、version 17より前のバージョンでは、暗号化されたパスワードは悪用される可能性がありました。例えば、難読化されていて少しの努力で解読される可能性があるなど。さらに、ODBC administrator を使用して、暗号化されたパスワードをプレーンテキストのパスワードにコンバートすることも可能でした。

備考: version 17 の新機能として説明していますが、ここで説明している encryptedpassword の変更は、 実際は version 16 build 2039 以降から利用可能です。

version 17 では、暗号化されたパスワードのサポートが強化されており、データベース管理者は、プレーンテキストのパスワードをユーザーに教えなくとも、データベースのアクセスを特定のコンピューターの一人のユーザーに制限することができます。さらに、現在のパスワードがメモリーに復号化され調査されることになるのを防ぐことができます。

復号化の成功を特定のコンピューターまたはコンピューターとユーザーの組み合わせに制限することが可能なため、プレーンテキスト内の暗号化されたパスワードを表示すること自体は、それほど問題ではありません。

例えば、下の接続文字列では、暗号化されたパスワード (ENP=) は、特定のコンピューターとユーザーの組み合わせ以外では誰も使用することができません。

dbping -d -c "Host=server-pc;Server=DemoServer;UID=DBA;ENP=05a17731bca92f97002100c39d906b70f3272fe76ad19c0e8bd452ad4f9ea9"

EncryptedPassword 接続パラメーターをよりセキュアにするために、以下の変更がされています。

1. 暗号化されたパスワードが容易に復号化されないよう、より強固な暗号化アルゴリズムが使用されています。
2. EncryptedPassword は、ある特定のコンピューター、またはある特定のコンピューターとユーザーの組み合わせに制限することが可能です。例えば、
   1. 暗号化されたパスワードは、特定のコンピューター上でしか復号化できず、他のどのコンピューターでも使用できない：しかしながら、そのコンピューターにログオンできる人は誰でも、データベースに対する認証にその暗号化されたパスワードとそのユーザーIDを使用することができます。
   2. その暗号化されたパスワードは特定のコンピューター上で特定のユーザーのみ復号化することができる：同じユーザーまたは別のユーザーでも、他のどのコンピューター上でも使用できません。
3. プレーンテキストパスワードは、SQL Anywhere のODBC 設定ダイアログを使用して EncryptedPassword 値からリバースエンジニアリングできなくなりました。SQL Anywhere のODBC 設定 Encrypt パスワードオプションは、チェックボックスでなくなり、以下のように別の暗号化オプションから選択して使用します。
   1. なし
   2. どのコンピューターでも使用
   3. このコンピューターのみの使用
   4. このコンピューターとこのユーザーのみの使用

このダイアログは、以前非暗号化でなかったかぎり、既存のパスワードのパスワード暗号化レベルを変更する目的では使用できません。暗号化のレベルを変更しなければならない場合には、パスワードを再入力する必要があります。

DBDSN の変更

Data Source ユーティリティ (dbdsn) では、暗号化されたパスワードの使用方法を指定する新しいオプション -pet a|c|u をサポートしました。

• -pet a が指定されている場合には、そのパスワードはどのコンピューターでも使用できるよう暗号化されます。
• -pet c が指定されている場合には、そのパスワードはこのコンピューターでのみ使用できるよう暗号化されます。
• -pet u が指定されている場合には、そのパスワードはこのユーザーがこのコンピューターで使用するためのみに暗号化されます。このオプションは、クライアントアプリケーションが windows サービスとして実行されている場合には使用できません。クライアントアプリケーションがサービスとして実行されている場合には、-pet c オプションをかわりに使用してください。
• 以前からある、単純な難読化を提供する -pe オプションは、継続してサポートされますが、これは廃止される方向です。

-pet c と -pet u オプションの暗号化は、使用する（復号化する）予定のコンピューターまたはコンピューター/ユーザー上で実行する必要があります。DSN 定義を他のマシンにエクスポートしてEncryptedPassword の使用を継続することはできません。

備考: 新しい暗号化されたパスワードの機能は、17.0.0.1272 と 16.0.0.TBDより前のバージョンのクライアントライブラリではサポートされていません。

DBFHide の変更

接続文字列(例：dbping -d -c @credentials.hidden)を認める多くのデータベースツールで使用するために、File Hiding ユーティリティ dbfhide ツールをファイルへの全接続文字列を暗号化するために使用することが可能です。version 17 では、新しいオプションである -wm (コンピューターのみ) と -w (コンピューターとユーザーのみ) をサポートしました。

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2015/09/17/sql-anywhere-17--a-more-wordly-savalidate-procedure

sa_validate() procedureは、本番システムがダウンする状況になる前に、あらゆるデータの破損をキャッチして対処できるようデータベースの様々な側面のバリデーションに使用できます。一般的にバックアッププロセスの一部としてバリデーションを実行することが好ましいとされています。

SQL Anywhere では、SQL Anywhere のイベントシステムを利用することで、これを自動化することができます。

以下にバックアップを実施する前にデータベースのバリデーションを実行するバックアップイベントの一例を紹介します。もし問題があれば、管理者に e-mail が送信されるようにします。

上記の例でおかしな点に気づかれたかもしれません。バリデーションの失敗を検出するには、特定の文字列を見つける必要があります。

SQL Anywhere の以前のバージョンでは、バリデーションエラーがないかどうか判断する唯一の方法は、‘No error detected’ という文字列を結果セットの中から見つけることでした。

しかしながら、これに関連する問題として、この文字列はまた SQL Anywhere がサポートしている全ての言語にローカライズされているため、全ての言語でこのチェックをコード化する直接的な方法がありませんでした。

version 17 では、sa_validate() 結果セットの既存の “Messages” カラムに新しく2つのカラムが追加されました。これにより、ディプロイメント言語を問わず、成功を継続的にチェックできるようになりました。

最初のカラムは “IsValid”で、bit 値です。バリデーションがクリーンな場合は 1 に設定され、バリデーションエラーがある場合は 0 に設定されます。

次のカラムは、“ObjectName” で、バリデーションがクリーンな場合は、空です。バリデーションエラーがある場合は、このカラムにはバリデーションに失敗したデータベースまたはテーブルの名前が含まれます。

上のバックアップイベントを、sa_validate() 結果セットにこの2つのカラムが含まれるようアップデートしてみます。

シンプルに “IsValid” カラムをチェックして、バリデーションの成功/失敗を判断することができます。

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2013/09/11/from-the-archives-cross-and-outer-apply

CREATE PROCEDURE high_salary( IN dept INTEGER )
RESULT ( name LONG VARCHAR )
BEGIN    SELECT E.emp_fname || ' ' || E.emp_lname         FROM Employee E        WHERE E.dept_id = dept AND E.salary > 80000;
END

SELECT D.dept_name, HS.name
FROM Department D CROSS APPLY high_salary( D.dept_id ) as HS

SELECT D.dept_name, HS.name
FROM Department D OUTER APPLY high_salary( D.dept_id ) as HS

SELECT D.dept_name, HS.name
FROM Department D OUTER APPLY (        SELECT E.emp_fname || ' ' || E.emp_lname        FROM Employee E        WHERE E.dept_id = D.dept_id AND E.salary > 80000    ) HS( name )

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2015/03/18/from-the-archives-limitations-of-proxy-tables

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2015/03/11/from-the-archives-update-statements-and-lower-isolation-levels

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2015/02/11/from-the-archives-analyzing-clustered-indexes

この記事のオリジナルは、Glenn Paulleyが sybase.com に2010年9月に掲載したものです。Glenn はこの中で、オプティマイザがどのようにクラスタードインデックスを利用するのか説明するとともに、クラスタードインデックスに関連する統計情報についても解説しています。この情報を理解することで、declareされたクラスタードインデックスが効果的に使用されているのか、またインデックスを再構築した方が良いのか判断するのに役立ちます。

===

　SQL Anywhereはバージョン8.0.2以来、クラスタードインデックスをサポートしてきました。SQL Anywhereにおいて、クラスタードインデックスと非クラスタードインデックスの間に物理的な違いはありません。また、参照整合性制約のメンテナンスのために暗黙的に作成されるインデックスなども含め、すべてのインデックスはクラスタ化することができます。さらに、ALTER INDEX文を使うことで、クラスタ化の属性を追加または削除できます。ただ、このクラスタ化はあくまで検索の''手がかり''であり、クエリがORDER BY句を含む場合はやはりソート処理が必要です。

　インデックスがクラスタ化されている場合（ちなみに宣言できるクラスタードインデックスの数は1つのテーブルにつき1つまでです）、ローが最初に挿入される際、データベースサーバは、テーブルページ内のローの物理的並び順を、クラスタードインデックスにおけるインデックスエントリの並び順にできるだけ一致させようとします。このようなクラスタードインデックスの利点は言うまでもなく、サーバがレンジスキャンの際にクラスタ化されたこの性質を活用できることです。クエリ処理時にクラスタードインデックスによる検索を行うと、読み込まなければならないテーブルページの数を最小限に抑えることができます。

クラスタ化に関する統計情報

　SQL Anywhereバージョン10からは、インデックスがCLUSTEREDとして宣言されているかどうかに関係なく、データベース内の各インデックスのクラスタ化に関する統計がサーバによって管理されるようになりました。こうした統計情報はSYS.SYSPHYSIDXシステムビューで見ることができ、また次のようなクエリを使って検索できます。

（続きは、2010年に翔泳社 CodeZine に掲載された翻訳記事をご覧ください。）

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2015/02/18/from-the-archives-snapshot-isolation-and-materialized-views

この記事のオリジナルは、Glenn Paulleyが sybase.com に2011年2月に掲載したものです。Glenn はこの中で、スナップショットアイソレーションとマテリアライズドビューを組み合わせて使用する効果について語っています。

===

私は以前の記事で、スナップショットアイソレーションの使用に関するトレードオフについて解説し、マテリアライズドビューの時間空間トレードオフに関する資料を紹介しました。スナップショットアイソレーションについての記事では、私は次のように書きました。

　もちろん、スナップショットアイソレーションもタダではありません。データベースシステムは、新規のスナップショットトランザクションを見越して、変更されたデータのアーカイブコピーを作成しなければならないのです。SQL Anywhereでは、スナップショットのローのコピーは自動的に管理され、必要に応じて一時ファイルに書き込まれます（一時ファイルのサイズは必要に応じて増加）。管理上の影響はほぼゼロですが、クエリのパフォーマンスには影響が出る可能性があります。スナップショットのローを、トランザクションのスナップショットセマンティクスに従って、一時ファイルに保存されているスナップショットのローから個別にフェッチしなければならないためです。パフォーマンスがどの程度低下するかは、ひとえにアプリケーションとそのワークロードに依ります。更新量が多い場合には、パフォーマンスの低下はひどくなるでしょう。

　今回の記事では、特にSQL Anywhereサーバのトランザクションログとの関連で、スナップショットアイソレーションとマテリアライズドビューの関係を解説し、そのトレードオフについても取り上げようと思います。

マテリアライズドビューをリフレッシュする

　遅延メンテナンス型のマテリアライズドビューの場合、マテリアライズドビューの基となるベーステーブルへの変更は、追加のロックや（即時）メンテナンスのオーバヘッドなしに進行していきます。つまり、更新トランザクションはベーステーブルの値またはローを変更し、COMMITの時点でその変更を確定します。しかしこの状態では、マテリアライズドビューの内容は古くなってしまいます。このようなマテリアライズドビューの古い内容をSQL文が利用できるかどうかは、そのクエリの接続に関するオプション設定に左右されます。ビューの内容をリフレッシュするには、そのビューに対してREFRESH MATERIALIZED VIEW文を発行します。このSQL文は、事実上、対象のビューを含んでいるベーステーブルに対してTRUNCATE TABLEを実行した後、すぐさまINSERT ... FROM SELECTを実行してマテリアライズドビューにデータを挿入します。

　一方、即時メンテナンス型のマテリアライズドビューの場合には、最初にビューにデータを挿入する時にだけREFRESH MATERIALIZED VIEW文が必要です。それ以降は、基となるベーステーブルに変更を加えたときに、同じトランザクション内で、そのベーステーブルを参照している即時メンテナンス型のマテリアライズドビューに変更が適用されます。このトランザクションは、完了時にCOMMITを実行して変更を確定するか、ROLLBACKを発行して変更を取り消します。

===

（続きは、2011年に翔泳社 CodeZine に掲載された翻訳記事をご覧ください。）

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2014/05/21/what-exactly-is-thread-deadlock

この記事のオリジナルは、Glenn Paulleyが sybase.com に 2009 年 5 月に掲載したものです。Glenn はこの中で、SQL Anywhere におけるスレッドデッドロックについて解説するとともに、アプリケーション設計に起因する問題について解説しています。

SQL Anywhere の最新のバージョン（16 以降）では、マルチプログラミングレベルを動的に調整するため、ほとんどの場合 -gn サーバーオプションを設定する必要はありません。しかしながら、これによって Glenn が以下で語っている好ましくない設計を隠すことができたとしても、根本的な解決にはならないことに注意してください。

===

スレッドデッドロックとは、 SQL Anywhereサーバーがある特定のリクエストに対して返す特定のエラー (SQLCODE -307, SQLSTATE '40W06') のことです。このブログ記事では、スレッドデッドロックがなぜ、どのように発生するのか、さらには問題の診断に利用できるメカニズムについてまとめたいと思います。

SQL Anywhere のスレッディングアーキテクチャー

他のデータベース管理システムと同様、SQL Anywhere では基本となるオペレーティングシステムのスレッディングモデルだけに依存するのではなく、独自のスレッディングアーキテクチャーを実装しています。SQL Anywhere は、幅広い OS とハードウェアプラットフォームをサポートしているため -- いくつかを挙げると、Windows、Linux、Windows CE、Sun OS、AIX、HP-UX、Mac OS/X など -- SQL Anywhere では、オペレーティングシステム上の（例：Windows、Linux）それらをサポートする「lightweight」スレッド (fibersとも呼ばれる) と、これらの OS プラットフォーム上の通常の OS スレッドを利用します。

また、SQL Anywhere ではサーバーは特定の一つのスレッド（fiber）を一つの接続に占有させるのではなく、サイズが固定されたサーバースレッドのプールが、サーバーに入ると複数のタスクに動的にアサインされて実行されます。タスクは、アプリケーションまたはストアドプロシージャーからのSQL 文であることが多いものの、一つのスレッドがサービスできるタスクには、様々なタイプがあります。一旦スレッド（fiber）上でタスクがスケジュールされると、 そのスレッドは、そのタスクが完了するまで、またはキャンセルされるまでそのタスクを処理するようアサインされます。

SQL Anywhere は、デフォルトではサーバーがスタートするとスレッドを 20 作成します (Windows CE では 3 です)。このデフォルト設定は、-gn コマンドラインスイッチを使用することで変更することができます。実際はスレッド数がサーバーのマルチプログラミングレベル -- 1 回にアクティブにできるタスクの最大数 -- を決定することになります。サーバースレッドは、そのサーバー上のどのデータベースへの接続数からも独立しています。そのため、ある任意のスレッド (fiber) は、まず データベースのためのタスクをサービスしてから、別のデータベースへの接続のタスクをサービスすることができます。

スレッドデッドロック - 条件

SQL Anywhere サーバーのスレッドは、PREPARE、DESCRIBE、OPEN、FETCH のようなもともとはデータベースリクエストであるタスクをサービスします。これらのタスクはとても高速でサービスされることが多いものの、大きな結果セットを INSENSITIVEカーソルでオープンするような場合などでは、かなり遅くなることがあります。どこかのポイントで、そのタスクをサービスしているスレッドが、クエリーアクセスプラン演算子を実行している、結果式をアウトプットバッファーにマーシャリングしている、I/O演算子が完了するのを待機している、あるいはシェアードサービス上でブロックされている可能性があります。例えば、スキーマロックや行ロックなどです。

マルチプログラミングレベルが n だとすると、スレッドデッドロックとは、 n-1 スレッド (fibers) がアクティブタスクをサーブしているもののブロックされており、アクティブタスクをサーブしている nth スレッド (fiber) もまさにブロックされそうな状態のことです。サーバーは、全てのスレッド (fibers) がブロックされるのを防がなければなりません。なぜならば、これが結果的にはエンジンが「ハング」してしまうことになるからです -- つまり、スレッドは全てブロックされているため実行不可能で、新たな接続もハンドリング不可能、そして全ての新しいタスクが待機状態になります。

この状況は、「本当の」 デッドロックとは、以下の意味において異なります。「本当の」デッドロックとは、二つまたはそれ以上のスレッドにおいて、継続できるスレッド（fibers）がないというような依存のサイクルができてしまうことです。

それに対して、スレッドデッドロックでは、完全に関係ない SQL リクエストの場合にブロックされる可能性があります。それぞれがサーバースレッド (fiber) を 結びつけ、スレッドが SQL リクエストをブロックしようと試みると、エラー -307 を受け取ります。サーバーのスレッド (fibers) のセットは、別々のデータベースに接続している接続に対しても、全ての SQL リクエストをサービスするため、それぞれのデータベースの結びつけられたワークロードが原因でスレッドデッドロックが発生する可能性があるということに注意してください。

何十、何百もの接続をサービスするビジーなサーバーの場合、データベースのサイズまたはブロッキングが原因で多くのリクエストが long-running の場合にはスレッドデッドロックになる可能性があります。この場合に適切な解決策は、-gn コマンドラインスイッチを使用して、より高い値でサーバーを再起動することにより、サーバーのマルチプログラミングレベルを増加させることです。

しかしながら、アプリケーションシステムでは、アプリケーションの設計に起因する過度あるいは意図しない接続で、スレッドデッドロックになることが頻繁に発生します。このような場合には、アプリケーションをより大きなデータセットまたは接続数にスケールすることで問題をさらに悪化させてしまいます。また、マルチプログラミングレベルを高い値に上げることで、問題を解決できることはめったにありません。

どのようにしてスレッドデッドロックは発生するのか

スレッドデッドロックのインスタンスを（簡単に）入手する方法を説明するために、それぞれのクライアントが定期的に「センサーデータ」の行を挿入するシンプルなマルチクライアントの例を使ってみます。「センサーデータ」は、以下のテーブルに格納します。

さらに、クライアントがセンサーデータの行を挿入するごとに、クライアントはそのセンサーの挿入レコード記録の総数を含むサマリーレコードを更新します。サマリーデータテーブルは、以下のとおりです。

それぞれのクライアント接続のロジックは、以下のストアドプロシージャーにあらわされています。

上記のプロシージャー内のロジックは簡単です。最初のステップ で、センサーデータの行を sensor_data テーブルに挿入します。次のステップで、サマリーテーブルを修正します。複雑なのは、問題のセンサーのサマリー行があるかどうかを決定することです。もしあれば、その行のカウントは、インクリメントされ 、なければ、新しい行が挿入されます。

注意: 上記のコードは簡単ですが、誤りでもあります。このプロシージャーのロジックは、文字通りrace条件を含み、使用されている分離レベルによって、頻繁にデッドロックと/または不正確な結果を引き起こします。ただし、これに関する詳細は、ここで説明しようと思っているスレッドデッドロックのケースでは、重要ではありません。

この例をセットアップするには、リクエストのレスポンス時間をトラッキングするために samples/trantest ディレクトリの trantabs.sql スクリプトを実行し、TRANTEST ユーティリティーが利用するテーブルもセットアップする必要があります。セットアップには、以下も必要になります。

SQL Anywhere サンプルの TRANTEST パフォーマンス分析ユーティリティを使用して、上記のプロシージャーを同時に複数の接続から実行します。TRANTEST コマンドラインは、以下のとおりです。

まとめると、TRANTEST は ESQL 接続を 25 作成し、"insert_sensor_data.sql" 内のスクリプトを、think time ゼロ、分離レベル2、総経過時間15秒で継続的にコールし、5 トラザクションごとにCOMMITを発行します。"insert_sensor_data.sql" ファイルには単一の line が含まれます。

11.0.1 サーバーを実行しているので、デフォルトマルチプログラミングレベル20で、25クライアントを選択します。

スレッドデッドロックの問題判別

スレッドデッドロックが発生し、接続のセットとSQL リクエストが含まれているかどうか判断するには、２つの方法があります。１つはビルトインの診断プロシージャー sa_report_deadlocks() を使う方法で、これは上記 LOG_DEADLOCKS オプションを有効にすることで可能です。TRANTEST で上のサンプルを実行後の結果の一部が以下です。

Line 54-67 は、スレッドデッドロックを示す DBISQL ウィンドウです。ここでは、最初の行 (line 54) が、「victim」 (CALL文は 、最後のブロックされていないスレッドを実行していました) です。続く行は、他の接続の状況を示します。もちろん、これらそれぞれは、INSERT_SENSOR_DATA()  プロシージャーを実行している間ブロックされています。sa_report_deadlocks() で返される行は、テーブル (object 3358、summary_data テーブル、 SYSOBJECTS カタログテーブルから) と、ブロックを発生させている summary_data 内の行の行識別子のどちらも詳細しています。

原因は簡単です。なぜならば、プロシージャーは、summary_data テーブルの行の読み込み (プロシージャーの line 16) と変更 (line 17) のどちらも試み、マルチプルクライアントが互いにブロックするからです。可能なスレッドよりも多くのクライアント、バッチド COMMIT、zero think time で、スレッドデッドロックは必然です。-gn をクライアントの数よりも高い値に増やすことで、スレッドデッドロックの発生を防ぐことができますが、根本的な問題、INSERT_SENSOR_DATA() プロシージャーの実行のシリアル化、の解決にはなりません。

スレッドデッドロックの存在を発見する２つめの方法は、SQL Anywhere の Sybase Central (現 SQL Central) から Application Profiling 機能を使用することです。Application Profiling を開始し、TRANTEST を実行することで、どの接続によっても発行される各ステートメントの実行を記述するトレーシングデータベースを産出します。このテストのサマリーページを Sybase Central で表示すると以下のようになります。

2009/09/thread_deadlock_summary.png

UPDATE summary_data ステート文のサマリー時間に注意してください。9300-odd ステートメントの呼び出し総時間は 2910 ミリ秒です。 しかし、最大時間の 213 ミリ秒は、過度のブロッキングのサインです。詳細ペイン移動すると、スレッドデッドロックの発生は明白になります。

この詳細なビューから、それぞれのスレッドデッドロックが発生した時点で同時実行ステートメントを分析することができ、サーバーの各スレッドの何がその時何を実行していたのか判断することができます。そしてそれが、繰り返しますが、うまく書かれていない INSERT_SENSOR_DATA() ストアドプロシージャー、そして特に、summary_data テーブル上のUPDATEステートメントを指摘することになります。

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2014/04/09/using-regular-expressions-with-sql-anywhere

この記事のオリジナルは、Glenn Paulleyが sybase.com に 2009年 6 月に掲載したものです。Glenn はこの中で、SQL Anywhere のクエリ内で正規表現を使用する方法について解説しています。

SQL Anywhereの version 11.0.0 では、正規表現検索を含む検索条件が実装されました。使用可能な正規表現検索述部には、２種類のバリアントがあり、それぞれに独自のセマンティクスがあります。 SIMILAR TOと REGEXPです。

SIMILAR TO

SIMILAR TO述部は、ANSI/ISO SQL 2008 の一部です。しかしながら、2011年の次の標準 SQLのドラフトは、現在作成途中で、WG3 編集ミーティングがまさに今週韓国で開催されています。そして、SIMILAR TO は、標準 SQL 規格の次のバージョンからは除かれるようです。というのも、この機能は、REGEXP_LIKE述部 (以下を参照してください）に代わる方向だからです。

SIMILAR TO 述部のシンタックスは、簡単です。

しかしながら、いつものように、「devil (厄介な点)」は詳細部分にあります。スターターのために、以下に SQL Anywhere デモデータベースを使用した例を挙げます。

上記は全て無効な郵便番号（米国とカナダのどちらか）をもつアドレスであることがわかります。受けつけられるコードは、 (a) 5桁の番号 (US)、(b) ５桁の番号、ダッシュ、4桁の番号 (US) そして (c) ６桁のアルファベットと数字を組み合わせと埋め込まれた空白が1つのカナダの郵便番号の形式です。

しかしながら、SIMILAR TO でサポートされている正規表現のパターンは、他のソフトウェアパッケージ（例えば Perl など）でサポートされている正規表現条件とは異なります。以下に、相違点の一部をリストします。（詳細は、SQL Anywhere のマニュアルに記載されています。)

• LIKEや REGEXPのように、SIMILAR TO は、全体の値にマッチしますが、値の一部にはマッチしません。
• SIMILAR TO は、"%" (パーセント) と "_" (下線) をLIKE と同じようにワイルドカード文字として使用します。".*"のかわりに、"%" を使用することができます。
• SIMILAR TO は、[:ascii:]、 [:blank:]、 [:punct:]のような様々な 部分文字をサポートしていません。
• おそらく、最も重要なのは SIMILAR TOが string 値を比較する場合に、照合ベースの比較を使用することです。これは、便利かもしれません。例えば、SQL Anywhere のデフォルトの大文字・小文字を区別する文字列マッチングでは、パターン [A]{1} は [a]{1} と同等です。そして、これらの同一性は、アクセント記号付文字の特定の照合にも適用される可能性があります。しかしながら、重要な欠点は、レンジパターンが、適切に機能しないことです。レンジパターン [A-C] は、実際、大文字 A、B、Cにのみマッチするわけではありません。デフォルトの大文字・小文字を区別する照合 [A-C] は、A、B、b、c、C のどの文字にもマッチします。 "a" とは マッチしません。なぜならば、"a" の文字は、照合順において"A" に先行しないからです。
  
  これは、上の例ではカナダの郵便番号を適切にバリデートできないことを意味しています。このクエリは、小文字を含むカナダの郵便番号を受けつけてしまいます。

REGEXP

SQL Anywhere 11.0.1 では、REGEXP述部は、正規表現検索をサポートしている Perl やその他の UNIX ベースのツールの方式で正規表現パターンをサポートしています。繰り返しますが、シンタックスは簡単です。

標準 SQL において、述部キーワード LIKE_REGEXP を使用するという例外を除けば、シンタックスはバーチャルに同一です。サポートされているパターンは、標準の XQuery 部分からのものです。SQL Anywhere では、様々なソース、特に Perl からパターンシンタックスを採用してきました。 REGEXPは、照合ベースのマッチングを使用しません。マッチングは、データベースキャラクターセットのコードポイント値に基づいています。例えば、単一の文字 X の比較X REGEXP '[A-C]'は、CAST(X AS BINARY) >= CAST(A AS BINARY) AND CAST(X AS BINARY)と同等です。REGEXPは、プログラマーにとってなじみのある共通のメタ文字やサブクラスをサポートしています。また、特別なエスケープ文字、例えばスペースの "\s"、キャリッジリターンの "\r"、そして先読みアサーションや後読みアサーションなどの文字もサポートしています。下は、郵便番号をバリデートする同じ例ですが、今回は REGEXPを使用しています。

最後に、SQL Anywhere のクエリオプティマイザーは、特定のパターンによって、インデックススキャンの sargable 述部として使用するため、自動的に REGEXP と SIMILAR TO 述部を -- LIKE 述部 と同様に -- 最適化することに注意してください。

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

http://scn.sap.com/community/sql-anywhere/blog/2014/03/19/why-snapshot-isolation-is-so-useful

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、過去sybase.comに掲載されていたホワイトペーパーの抄訳です。

===

このホワイトペーパーは、SQL Anywhere 12 をベースに書かれていますが、ほとんどの部分で過去のバージョンや将来のバージョンでも利用可能です。また、英語のホワイトペーパーをそのまま翻訳しているため、製品画面ショットなどは英語版ソフトウェアのものですが、SQL Anywhereは、日本語にローカライズされています。

はじめに

必要なソフトウェア

概要

Northwind SQL Server  データベース用の  ODBC  データソースの作成

新しい  SQL Anywhere Database  の作成

SQL Server  から  SQL Anywhere  へのスキーマとデータの移行

移行したデータベースのスキーマとデータの確認

ビューの移行

データベースロジックの移行

ストアドプロシージャー

ユーザー定義関数とトリガー

適切な動作の確認と検証

まとめ

はじめに

このチュートリアルでは、Microsoft SQL Server データベースを SQL Anywhere データベースに移行する方法について、実例とともに説明します。スキーマとデータを移行するには、SQL Anywhere に用意されているデータベース移行ウィザードを使用します。データベースロジック (ストアドプロシージャー、ユーザー定義関数、およびトリガー) を移行するには、T-SQL コードに若干の修正を加えて、適切に動作するようにします。このチュートリアルでは、SQL Server のサンプルデータベース "Northwind" を新しい SQL Anywhere データベースに移行します。

必要なソフトウェア

• SQL Anywhere 12.0.1 以降

• Microsoft SQL Server (2008 R2 Express バージョンでテスト済みですが、他のバージョンでも有効です)

• Northwind サンプルデータベース

Northwind サンプルデータベースが実際の SQL Server インストールで適切にアタッチおよび構成されていることを確認してください。

SQL Server が混合モード認証で構成され、システム管理 "sa" アカウントが有効になっているという前提です。

このチュートリアルは、Windows オペレーティングシステム向けに作成しています。

概要

このチュートリアルで扱う範囲は、次のとおりです。

• Northwind SQL Server データベース用の ODBC DSN の作成

• Sybase Central による新しい SQL Anywhere データベースの作成

• データベース移行ウィザード による SQL Server データベースからのスキーマとデータの移行

o SQL Server を参照するリモートデータベースサーバーの作成

o 新しい SQL Anywhere データベースへのスキーマとデータの移行

• SQL Anywhere データベース内部へのストアドプロシージャーとその他のデータベースロジックの生成を目的とする、SQL コードの修正

SQL Server には、AdventureWorks という高度なサンプルデータベースも用意されています。このデータベースの SQL Anywhere バージョンは、こちらから入手できます。

Northwind SQL Server データベース用の ODBC データソースの作成

SQL Anywhere データ移行ツールは、SQL Server データベースへの ODBC 接続を必要とします。Sybase Central は ODBC データソースに基づいて「リモートデータベースサーバー」を作成し、SQL Anywhere 管理ツール (Sybase Central と Interactive SQL) による SQL Server データベースへのアクセスとクエリの実行を可能にします。この機能は、Remote Data Access と呼ばれています。

1. ODBC Administrator を開いて ([スタート] -> [すべてのプログラム] -> [SQL Anywhere 12] -> [Administration Tools] -> [ODBC Data Source Administrator])、[Add]をクリックします。

2. リストから [SQL Server] を選択して、[Finish]をクリックします。

3. [Microsoft SQL Server DSN Confuguration wizard] が表示されます。次のデータベース接続オプションを入力します (ウィザードのページ間を移動するには [Next]または [Back] をクリックします)。

o データソース名に Northwind-SQLServer を指定します。

o 接続先の SQL Server インスタンスのサーバー名または IP アドレスを指定します。

o 適切なクライアント構成 (TCP/IP、サーバー別名など) を指定します。

o 適切なログイン資格情報 (ログイン ID とパスワード) を指定します。

o デフォルトのデータベースを Northwind に変更します。

o その他のオプションはすべて、デフォルト設定を使用します。

4. [Finish]をクリックし、ウィザードを終了します。[OK] をクリックし、[SQL Server Setup] ダイアログを閉じます。

5. [OK] をクリックし、ODBC Administrator を閉じます。

新しい SQL Anywhere データベースの作成

以降の操作はすべて、SQL Anywhere の管理ツール Sybase Central で実行します。

1. Sybase Central を起動します ([スタート] -> [すべてのプログラム] -> [SQL Anywhee 12] -> [Administration Tools] -> [Sybase Central])。[Tips] ダイアログおよび／または [Welcome] ダイアログを閉じます (表示された場合)。

2. [Tools] メニューから、[SQL Anywhere 12] -> [Create Database] を選択します。[Create Database Wizard] が表示されます。

3. [Create a database on this computer] を選択して、[Next] をクリックします。

4. データベースファイルを northwind.db という名前で保存します。

5. この時点で、新しいデータベースのデフォルト設定 (ページサイズ、暗号化、大文字小文字の区別など) を変更できますが、このチュートリアルでは省略します。[Finish]をクリックし、データベースを作成します。

6. データベースが正常に作成されたら、[Close] をクリックし、[Create Database Wizard] を閉じます。

Sybase Central は、新しく作成した "northwind" SQL Anywhere データベースに自動的に接続します。その際には、デフォルトのユーザーアカウント "DBA" が使用されます。このデータベースは、初期状態では空です (スキーマやデータは存在しません)。

注：別の方法として、dbinit コマンドラインユーティリティで新しい SQL Anywhere データベースを作成してから、Sybase Central を使用して、そのデータベースに接続するという方法もあります。

SQL Server から SQL Anywhere へのスキーマとデータの移行

SQL Server データベースから、新しく作成した SQL Anywhere データベースにスキーマとデータを移行するには、データベース移行ウィザードを使用します。このウィザードに従って、ソース (SQL Server) データベースのスキーマと適合するテーブル、インデックス、キーのリレーションシップをすべて作成します。その後、すべてのローをソースからターゲット (SQL Anywhere) データベースにコピーします。

1. Sybase Central で、[Tools] メニューから、[SQL Anywhere 12] -> [Migrate Database] を選択して、ウィザードを起動します。

2. "northwind" データベースを選択して、[Next] をクリックします。

3. 移行するデータベースオブジェクトは、"northwind" SQL Server データベースに格納されています。テキストボックスに northwind と入力して、[Create Remote Server Now] をクリックします。

4. リモートサーバー名として NorthwindMSSQLRemoteServer を入力して、[Next] をクリックします。

5. リモートサーバータイプのリストから [Microsoft SQL Server] を選択して、[Next] をクリックします。

6. これで、ウィザードでは、ODBC を使用して SQL Server データベースに接続することになります。接続情報 (先に作成した ODBC データソース) として Northwind-SQLServer を入力して、[Next] をクリックします。

7. 選択すれば、リモートサーバーを読み取り専用データソースとして設定できます。今回の場合では、デフォルト設定のままにして、[Next] をクリックします。

8. SQL Anywhere データベースへの接続は、ユーザー名 "DBA" が使用されます。リモートサーバー (SQL Server) では、このユーザーは認識されないので、外部ログインを作成して、(SQL Anywhere の) DBA ユーザーを、Northwind データベーススキーマを操作できる SQL Server ユーザー (今回の場合では、"sa") にマッピングさせる必要があります。[Create an external login for the current user] をオンにして、SQL Server のデータベースサーバーにログインするための適切な資格情報を入力します。[Next] をクリックします。

9. 概要ページが開き、リモートサーバーを作成するために SQL Anywhere で実行される SQL 文が表示されます。[Finish] をクリックし、リモートサーバーを作成します。

10. これで、データベース移行ウィザードに戻ります。新しく作成した "NorthwindMSSQLRemoteServer" を選択して、[Next] をクリックします。

11. 左側のリストボックスに、Northwind SQL Server データベースのテーブルがすべて表示されます。テーブルをすべて移行するので、[Add All]、[Next] の順にクリックします。

12. この時点で、選択すれば、"DBA" ユーザーまたは他のユーザーにテーブルを追加できます。わかりやすくするため、今回の場合では、テーブルを DBA ユーザーに追加します。DBA ユーザーを選択して、[Next] をクリックします。

13. [Specify Migration Options] ページが表示されます。外部キーおよび／またはデータを移行するオプションが用意されています。移行プロセスでは、プロキシテーブルを使用して、リモートデータベースサーバーのテーブルに対してクエリを実行します。オプションをすべてオンにしたままの状態で、[Next] をクリックします。

14. [Summary] ページが開き、スキーマとデータを移行するために実行される SQL 文が表示されます。各文はシステムストアドプロシージャーで構成されており、データベース移行ウィザードによって実行されます。ただし、アプリケーション内で実行することも可能です。特定のテーブルやリモート外部キーのマッピングを移行する必要がある場合は、移行システムストアドプロシージャーが役立ちます。

15. [Finish] をクリックし、移行を開始します。データベース移行ウィザード によって、Northwind SQL Server データベースから Northwind SQL Anywhere データベースにスキーマとデータが移行されます。処理が正常に完了したら、[Close] をクリックし、ウィザードを閉じます。

移行したデータベースのスキーマとデータの確認

1. Sybase Central で、右ペインの [Tables] をダブルクリックします。Northwind SQL Server データベースのテーブルはすべて、Northwind SQL Anywhere データベースに移行済みです。

2. テーブル [Customers] をダブルクリックし、カラム定義を表示して、SQL Server データベースのスキーマと適合していることを確認します。

3. それぞれ対応するタブで、制約、外部キー、インデックスなどを確認できます。[Data] タブをクリックし、ローを表示します。

ユーザー、グループ、リモートサーバー、インデックスなど、データベースのその他のオブジェクトは、Sybase Central で確認できます。

ビューの移行

データベース移行ウィザードでは、SQL Server データベースに定義されているビューおよびマテリアライズドビューは移行されません。したがって、この移行手順は手動で実行する必要があります。幸い、SQL Server のビューの生成に使用するクエリは、SQL Anywhere の場合のクエリに若干の修正を加えるだけで流用できます。元の Northwind SQL Server データベースには、16 個のビューが定義されています。下記の SQL コードは、SQL Server の Northwind サンプルデータベースに用意されていた instnwnd.sql に修正を加えて流用したものです。SQL Server Management Studio を使用して、各ビューの SELECT 文を確認することもできます。

1. Sybase Central で、[View] メニューから [Folders] を選択して、[Folders] ビューに切り替えます。

2. 左ペインで、[Views] を右クリックし、ポップアップメニューから [New] -> [View] を選択します。

3. ビュー名として Invoices を入力して、[Next] をクリックします。

4. 次の SQL 文を入力して、ビューを定義します。

5. SQL Server と SQL Anywhere の SQL ダイアレクトには相違があることに注意してください。ただし、コード自体はほとんど同じです。

6. [Finish] をクリックし、ウィザードを終了します。SELECT 文に問題がある場合は、Sybase Central からエラーが生成されます。

7. 右ペインの [Data] タブをクリックし、ローを表示します。

上記の手順を繰り返して、残りの 15 個のビューを作成します。

Alphabetical list of products (製品名のアルファベット順リスト) ビューを作成する SQL 文：

Product Sales for 1997 (1997 年の製品別売上) ビューを作成する SQL 文：

Category Sales for 1997 (1997 年のカテゴリ別売上) ビューを作成する SQL 文：

Current Product List (現在の製品リスト) ビューを作成する SQL 文：

Customer and Suppliers by City (地域別顧客およびサプライヤー) ビューを作成する SQL 文：

Order Details Extended  (注文明細) ビューを作成する SQL 文：

Orders Qry (注文クエリ) ビューを作成する SQL 文：

Order Subtotals (注文小計) ビューを作成する SQL 文：

Products Above Average Price (平均価格超過の製品) ビューを作成する SQL 文：

Products by Category (カテゴリ別製品) ビューを作成する SQL 文：

Quarterly Orders (四半期単位の注文) ビューを作成する SQL 文：

Sales by Category (カテゴリ別売上) ビューを作成する SQL 文：

Sales Totals by Amount (数量別売上合計) ビューを作成する SQL 文：

Summary of Sales by Quarter (四半期別売上集計) ビューを作成する SQL 文：

Summary of Sales by Year (年別売上集計) ビューを作成する SQL 文：

データベースロジックの移行

データベースごとに SQL ダイアレクトには相違があるので、ストアドプロシージャー、ユーザー定義関数、およびトリガーの完全な移行機能を備えたツールはありません。ただし、SQL Server と SQL Anywhere の SQL ダイアレクトには相違はありますが、共通する部分も数多くあります。インスタンスによっては、同じ SQL 文が両製品で適切に動作します。ただし通常、ビジネスロジックを想定どおりに実行するには、SQL 文に若干の修正を加える必要があります。下記の SQL コードは、SQL Server の Northwind サンプルデータベースに用意されていたファイル instnwnd.sql に修正を加えて流用したものです。

ストアドプロシージャー

元の Northwind SQL Server データベースには、7 個のストアドプロシージャーが定義されています。このストアドプロシージャーを今回の Northwind SQL Anywhere データベースに移行するには、若干の修正を加える必要があります。

1. Sybase Central の左ペインで、[Procedures and Function] を右クリックし、ポップアップメニューから [New] -> [Procedure] を選択します。

2. [Create Procedure Wizard] が表示されます。プロシージャー名として CustOrderHist を入力します。[Next] をクリックします。

3. 別の SQL ダイアレクトや SQL 言語を使用して、プロシージャーのコードを記述することもできます。[Watcom-SQL] を選択して、[Next] をクリックします。

4. 今回の場合は、プロシージャーにコメントを入力する必要はありません。[Finish] をクリックし、ウィザードを終了します。

コードエディターが再表示されるので、プロシージャーの SQL コードを記述します。次のように CustOrderHist プロシージャーのコードを入力します。

5. ツールバーの [Save] ボタンをクリックするか、[File] メニューを使用して、プロシージャーを保存します。コード内にエラーがある場合は、Sybase Central から通知されます。

上記の手順を繰り返して、残りの 6 個のプロシージャーを作成します。

CustOrdersDetail (顧客注文詳細) プロシージャーを作成する SQL コード：

CustOrdersOrders (顧客別注文) プロシージャーを作成する SQL コード：

Employee Sales by Country (国別従業員売上) プロシージャーを作成する SQL コード：

SalesByCategory (カテゴリ別売上) プロシージャーを作成する SQL コード：

Sales by Year (年別売上) プロシージャーを作成する SQL コード：

Ten Most Expensive Products (販売価格上位 10 製品) プロシージャーを作成する SQL コード：

ユーザー定義関数とトリガー

Northwind サンプルデータベースには、トリガーのユーザー定義関数は用意されていません。ただし、これに該当するオブジェクトを SQL Server から SQL Anywhere に変換するプロセスは、ストアドプロシージャーを変換する場合と同じです。SQL Anywhere で関数およびトリガーを定義して呼び出す方法は SQL Server の場合と若干異なるので、その方法のセマンティックをよく理解しておく必要があります。

SQL Server から SQL Anywhere に関数とトリガーを変換する場合の例については、サンプルデータベース AdventureWorks for SQL Anywhere を参照してください。

適切な動作の確認と検証

スキーマ、データ、およびロジックの移行が終了したら、新しい (SQL Anywhere) データベースが古い (SQL Server) データベースと同じように動作することを確認することが重要になります。場合によっては、アプリケーションの標準的なテスト手順を実行して、想定外の動作が発生しないことを確認する必要があります。最低でも、いくつかの SQL クエリを実行して、結果セットが適切であることを確認してください。

1. Sybase Central の左ペインで、[northwind - DBA] を右クリックし、ポップアップメニューから [Open Interactive SQL] を選択します。この操作によって、Interactive SQL (アドホッククエリを実行するグラフィカルツール) が起動して、Northwind SQL Anywhere データベースに自動的に接続します。

2. 次の SQL クエリを入力して、Customers テーブルの内容を取得します。

3. [F5] を押すか、ツールバーの実行ボタンをクリックし、SQL クエリを実行します。下のパネルにクエリ結果が表示されます。

4. 結果セットが想定どおりであることを確認します。他のクエリをいくつか実行して、ビューとストアドプロシージャーをテストします。次にいくつかの例を示します。

この時点で、前の手順で SQL Anywhere データベース内に作成した、SQL Server にマッピングしているリモートサーバー (NorthwindMSSQLRemoteServer) は不要になるので、Sybase Central から削除できます。

まとめ

SQL Anywhere には データベース移行ウィザード と一連のシステムストアドプロシージャーが用意されており、SQL Server などのデータベースとの間でデータの迅速な移行を可能にします。テーブルオブジェクトの移行は、ほとんどの場合、ウィザードに従って手順を実行するだけで済みます。カスタムデータ型を使用している場合や、さらに柔軟な対応が必要な場合は、移行用のストアドプロシージャーを使用すると、実行する必要のある操作に応じてより詳細な対応が可能になります。

SQL Anywhere と他のデータベースの SQL ダイアレクトには相違があるので、ビューとデータベースロジックを移行する場合には、手順を手動で実行する方法が適しています。幸い、SQL コードには共通する部分が多く、移行プロセスは容易になっています。

スキーマとデータの移行が終了したら、新しい SQL Anywhere データベースを使用して、アプリケーションが適切に動作することを確認します。テスト手順を実行して、想定外の動作が発生しないことを確認します。

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

このページは、過去作成されたホワイトペーパーの抄訳です。

このホワイトペーパーは、SQL Anywhere 11 をベースに書かれていますが、ほとんどの部分で過去のバージョンや将来のバージョンでも利用可能です。また、英語のホワイトペーパーをそのまま翻訳しているため、製品画面ショットなどは英語版ソフトウェアのものですが、SQL Anywhereは、日本語にローカライズされています。

はじめに

システム要件

SQL Anywhere のデータ移行機能

データベース移行ウィザード

リモートデータアクセス

Oracle サンプルスキーマを移行する

ODBC データソースを作成する

新しいSQL Anywhere データベースを作成する

HR スキーマを移行する

はじめに

SQL Anywhere には、Oracle データソースから、SQL Anywhere への容易かつ迅速なマイグレーションが可能なビルトインの機能が実装されています。直観的なウィザードと、リモートデータアクセスの機能を使用することで、OracleデータベースからSQL Anywhere へ、スキーマとデータを移行することが可能です。SQL Anywhere へマイグレーションすることで、SQL Anywhere の自動管理と自動チューニング機能を利用することが可能です。

このホワイトペーパーでは、Oracle データベースに含まれているサンプルスキーマをSQL Anywhereへ移行する方法について解説します。

備考：（ノートPC、スマートフォン、タブレットPCなどの）リモートユーザーが、ローカルのデータベースとOracleを同期できるよう、Oracle データベースをモバイル化する方法について興味がある方は、こちらをご参照ください。（http://ftp2.ianywhere.jp/tech/oracle_ml30.pdf）

システム要件

• SQL Anywhere 11.0.1 またはそれ以降

• Oracle Database 11g R1 サーバー

• Oracle Database 11g R1 クライアント (ODBC)

• Oracle サンプルスキーマ (通常Oracle データベースとともにインストールされます)

データの移行について解説するにあたり、ここではversion 11g R1 を使用していますが、他のバージョンのOracle データベースにも適用することが可能です。

SQL ANYWHERE のデータ移行機能

他のソースからSQL Anywhere へデータを移行する場合、その方法には以下の2つのどちらかの選択肢があります。データベース移行ウィザード または リモートデータアクセス 機能です。

データベース移行ウィザード

データベース移行ウィザードは、Oracle データベースからSQL Anywhereへのマイグレーションを実行する方法として最もシンプルなものです。このウィザードを使用すると、データベースに格納されている主キーと外部キー、全ての行を含めたテーブルを移行することができます。また、このウィザードを使用することで、Oracle のテーブルにユーザー定義のデータタイプ（抽象データタイプ）でない限りは、スキーマとデータが移行されます。Oracle とSQL Anywhere では、ユーザー定義のデータタイプの実装が大きく異なるため、データベース移行ウィザードでは、Oracle の抽象データタイプを、相当するSQL Anywhereのものに適切にマッチさせることはできません。このようなケースに直面した場合は、次のセクションで説明するリモートデータアクセスの機能を使用することで、移行が可能です。

このホワイトペーパーでは、データベース移行ウィザードを使用して、Oracle Human Relations (HR) サンプルスキーマをSQL Anywhere へマイグレーションします。

リモートデータアクセス

リモートデータアクセス (Remote Data Access 、RDA) は、他のリレーショナルデータベースからSQL Anywhere へ、スキーマとデータをインポートするためのベースとなるメカニズムです。実際、RDA は、データベース移行ウィザードにおいても、データ移行プロセスを容易にするために使用されています。RDAを行う場合には、SQL Anywhere データベース内で「リモートサーバー」を定義します。次に、Oracle データベースにマッピングするリモートテーブルを表す 「プロキシーテーブル」を作成します。そして、プロキシーテーブルを使って、Oracle データベースに対してクエリを投げ、SQL Anywhere テーブルに結果セットをインポートします。

ORACLE サンプルスキーマを移行する

ODBC データソースを作成する

データベース移行ウィザードとリモートデータアクセスの機能には、Oracle データベースのODBC データソースが必要です。これには、2種類のODBC ドライバーの選択肢があります: 一つは、Oracle ODBC クライアントで、もう一つはiAnywhere Solutions Oracle ドライバー (現SQL Anywhere Oracle ドライバー、SQL Anywhere とともにインストールされます)です。どちらのケースでも、Oracle Net Manager アプレットを設定することで Oracle サンプルスキーマに確実にアクセスできることを確認してください。このホワイトペーパーでは、iAnywhere Solutions Oracle ドライバーを使用して、Oracle データベースサーバーにアクセスします。　

1. ODBC Administrator を起動して、新たなユーザーとSystem DSN を追加してください。「iAnywhere Solutions 11 – Oracle」ドライバーを使用します。

2. 「Oracle11g_Samples」と入力し、Oracle データベースにログインするために必要なクレデンシャルを入力してください。HR、OE、SHのサンプルスキーマにアクセス可能な user IDを入れてください。.

3. OK をクリックし、Finish をクリックしてODBC DSN を保存します。

新しいSQL ANYWHERE データベースを作成する

SQL Anywhere 管理プログラムである「Sybase Central」を使用してこのホワイトペーパーの残りのステップを実行します。

1. Sybase Centralを起動します: 以下の順でクリックします Start → Programs → SQL Anywhere 11 → Sybase Central

2. Tools メニューから、SQL Anywhere | Create Database を選択して、データベース作成ウィザードを起動します。

3. Welcome ページの Next をクリックします。

4. 「Select a database on this computer」を選択して Next をクリックします。

5. SQL Anywhere データベースファイルの名前と場所を指定します。例えば: C:\MigrateToSA\SampleSchemas.db.

6. データベース作成ウィザードでは、新しくSQL Anywhere データベースを作成するにあたり、例えば、暗号化の設定、ページサイズ、データベースの照合順など多数のオプションが用意されています。ここでは、新しいデータベースに対して追加のオプションは必要ないので、シンプルにデフォルトの設定を採用し、Finish をクリックしてウィザードを終了します。

7. Sybase Central で新しいデータベースを作成します。オペレーションが完了したら、Close をクリックします。

これで、新しく作成したSQL Anywhere データベース「SampleSchemas.db」に接続され、移行プロセスを開始することができます。

HR スキーマを移行する

データベース作成ウィザードを使用してHR スキーマを移行するのは、とても簡潔です。

1. Tools メニューから、SQL Anywhere | Migrate Database を選択して、データベース作成ウィザードを起動します。

2. Welcome ページのNext をクリックします。

3. 「SampleSchemas」データベースを選択して、Next をクリックします。

4. Oracle データソースのリモートサーバーを作成する必要があります。Create Remote Server Nowをクリックして、リモート・サーバ作成ウィザードを起動します。

5. リモートサーバーの名前を指定します。例えば「OracleSamples」など。Nextをクリックします。

6. リモートサーバータイプのリストからOracle を選択します。SQL Server、DB2、MySQL などの他のデータベースソースからも移行が可能です。Next をクリックします。

7. 接続タイプとしてSelect ODBC を選択します。接続情報には、先に作成したODBC データソース名c「Oracle11g_Samples」を入力します。Next をクリックします。.

8. ここでは、Oracle データベースをアップデートする必要はないため、「Make this remote server a read-only data source」をクリックして、Next をクリックします。.

9. SQL Anywhere は、Oracle データベース内のサンプルスキーマにアクセスするために、外部ログインが必要です。「Create an external login for the current user」をクリックして、HR、OE SHにアクセスするための適切なクレデンシャルを入力してください。自由に接続をテストしてみてください。Finish をクリックします。.

10. データベース移行ウィザードに戻ります。新しく作成した「OracleSamples」リモートサーバー を選択し、Next をクリックします。Sybase Central がOracle データベースサーバーと通信する間数分かかることがあります。

11. Oracle データベースの全てのテーブルのリストが表示されます。「HR」に属するテーブルだけを選択し、Add All をクリックして、Next をクリックします。

12. 特定のユーザーのテーブルを移行します。この例では、異なるスキーマのSQL Anywhere ユーザーを作成しようとしています。Create User Now をクリックします。ユーザ作成ウィザードが表示されます。

13. しいユーザー名を「HR」とし、Next をクリックします。

14. HR ユーザーにパスワードをアサインします。例えば、「hr」など。ここではデフォルトの設定を使用するので、Finish をクリックしてウィザードを終了します。.

15. データベース移行ウィザードに戻り、新しく作成したユーザー「HR」を選択して、Next をクリックします。

16. 外部キーとデータを移行します。移行後、アクセスしたい場合には生成されたプロキシーテーブルをキープすることもできます。全てのオプションをクリックして、Finish をクリックします。

17. Sybase Central は、Oracle データベーススキーマをチェックし、適切なテーブルと外部キーリレーションを生成します。その後、Sybase Central は、Oracle インスタンスから SQL Anywhere データベースへデータをインポートします。メッセージダイアログは、Sybase Central が実行する異なるSQL 文を表示します。移行が成功したら、Close をクリックします。

18. これで、Sybase Central 内に生成したテーブルを見ることができます。右側の窓で、「Tables」をダブルクリックします。HR Oracleスキーマに属するテーブルが現れます。SQL Anywhere では、これらは HR ユーザーに属します。

19. テーブル「EMPLOYEES」をダブルクリックし、異なるタブをナビゲートして、移行されたスキーマとデータをチェックします。

• Columns タブは、テーブルのカラム定義を表示します (主キー、名前、データタイプ、サイズ、など)。

• Constraints and Referencing Constraints タブは、外部キーと参照テーブルを表示します。

• Indexes タブは、テーブル内の全てのインデックスを表示します。デフォルトでは、インデックスはクラスタされていません。

• Data タブは、Oracleデータベースから移行された全ての行を表示します。

これで、Oracle HR スキーマのSQL Anywhere版ができました。このスキーマのテーブル内のカラムは、データベース移行ウィザードがマイグレーションを簡単に実行できるようにシンプルなデータタイプを使用して定義されています。抽象データタイプで定義されているカラムを取り扱う場合は、データベース移行ウィザードではなく、SQL Anywhere　の Remote Data Access 機能を使用してください。

======================

ご購入に関するお問い合わせ

こちらよりお問い合わせください。

Oracle から SQL Anywhere へのマイグレーションセミナーを開催します。

ぜひご参加ください。

The Best-Run Businesses Run SAP

以下の日程でSQL Anywhere ハンズオンセミナーを開催いたします。

まだお席には余裕がございますのでぜひご参加ください。

===

　                                                                                                                2016年5月吉日

お客様各位

平素は格別のご高配を賜り厚く御礼申し上げます。

SAP SQL Anywhereのハンズオンセミナー第2回を開催いたします。

（4月25日に開催しましたSQL Anywhereのハンズオンセミナーと同じ内容です）

本年度は、Oracle SE1の市場である中小規模システムや、パッケージソフト、さらには、

クラウドやモバイル、SAP HANAとのデータ連携など、マルチにご利用いただける

RDBMS SAP SQL Anywhere について定期的にセミナーを開催しております。

去る 5月11日には、「SAP SQL Anywhere」のエンタープライズデータベースとしての機能や、
SQL Anywhereの特長的な機能である自己管理自己チューニング機能、他社製データベースからの移行ツール、

競争力の高いライセンス体系と価格をご紹介するとともに

株式会社バイナル様にオラクルからの移行事例をご紹介いただきました。

ご出席いただきました皆様、ありがとうございます。

これに続きまして今回は、実際にSQL Anywhereに触っていただき、技術者の懸念点である

導入へのハードルの低さをご体験いただくために、ハンズオンセミナーを開催いたします。

次回開催予定のマイグレーションセミナーとともにご参加いただければ幸いです。

世界で1200万以上のインストール実績を誇るSQL Anywhereをお客様のビジネスに

ぜひご活用ください。

皆様のご参加を、心よりお待ちいたしております。

　　　　　　　　　　　　　　　　　記

　　　　【SAP SQL Anywhere 1st ステップ - ハンズオンセミナー　第2回】

◆日時：2016年5月25日（水）18:30～20:00（受付時間：18:15～18:45）

◆場所：SAPジャパン 本社　セミナールーム

　　　　〒102-8022 東京都千代田区麹町1-6-4 SAPジャパンビル

  　　http://www.sap.com/japan/tokyo

◆アジェンダ：（予告なく変更する場合がございますのでご了承下さい）

・ハンズオン - SAP SQL Anywhereのインストール、管理（バックアップ、リカバリなど）

　　　　※4月25日に開催した内容と同じです。

◆受講対象者：

（non-ERP）アプリケーション開発者、データベース管理者

◆費用：無償

◆ハンズオンの環境について：

・ハンズオンに使用いたしますパソコンは、以下要件を満たす機種のご持参をお願いいたします。

　弊社ではご用意いたしませんのでご注意ください。

      -OS: Windows 7、8、10、2003/R2、2008/R2、2012/R2

                  （32bit、64bitどちらでも可）

　  -メモリ：2GB以上

      -ディスク： 空き１GB以上

・当日は、SQL Anywhere 17の無償Developer Editionを使用します。

可能な方は、事前にこちらからダウンロードください。当日コピーも可能です。

◆前提スキルについて

　以下のスキルをお持ちの方を想定したハンズオントレーニングとなっております。

  - Oracle、SQL Server等のRDBMS製品で開発もしくは運用等の経験のある方

◆補足事項：

・本ワークショップはSAPエデュケーションが提供する各種トレーニングの代替とする

ことを目的としておりませんので、あらかじめご了解いただきますようお願いいたします。

・募集人数が限られておりますので、確実にご出席いただける方にお申込みいただきますよう、

お願いいたします。

◆募集人数：30名（定員に達し次第締め切らせていただきます）

◆お知らせ：次回開催予定セッション内容

6/15 (水)13:00～（予定）SQL Anywhereへのマイグレーションセミナーを開催予定です。

ツールを利用した容易なスキーマの移行、SQL変換、データ移行などについてご説明いたします。

◆参加のお申込方法：

こちらへご連絡ください。

以下の日程でSQL Anywhere セミナーを開催いたします。

まだお席には余裕がございますのでぜひご参加ください。

===

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2016年5月吉日

お客様各位

平素は格別のご高配を賜り厚く御礼申し上げます。

本年度は、世界で1200万以上のインストール実績を誇り、TPC-Cベンチマーク（実際の

業務を想定したオンライントランザクション処理のベンチマーク）の価格性能比テスト

において、低価格のマシンで抜群の性能を実証して現在ダントツNo.1のポジションを

維持するSAPのRDBMS、SAP SQL Anywhereについて定期的にセミナーを開催しております。

SAP SQL Anywhereは、Oracle SE1の市場である中小規模システムやパッケージソフト、

さらには、クラウドやモバイル、SAP HANAとのデータ連携など、マルチにご利用いただける

RDBMSです。特にその優れた自動チューニングや自動管理機能により、多くのISV様

が開発や運用コストを削減され、利益をあげられています。

5/11には貿易関連ソリューションとしてトップシェアを誇る「TOSSシリーズ」を開発・

販売される株式会社バイナル様をお招きし、「TOSSシリーズ」のデータベースをOracle

からSAP SQL Anywhereに変更された背景や経緯、マイグレーションで苦労された点、

導入効果などについて語っていただきました。また、5/25にはハンズオンセミナーを開催し、

SQL Anywhereを実際に触っていただくことで、SQL Anywhereのインストール/設定や

運用の容易性を実感いただきしました。

今回のセミナーでは、SQL Anywhereに付属しているツールや、SAPが別途用意するツール

を使用し、Oracleなど他社製データベースからSQL Anywhereへ移行方法について、具体的に

解説し、移行におけるハードルの低さを実感いただきます。

皆様のご参加を、心よりお待ちいたしております。

　　　　　　　　　　　　　　　　　　記

　【Oracleなど他社製データベースからSAP SQL Anywhereへの移行方法解説セミナー】

◆日時：2016年6月15日（水） 13:00 ～ 15:00　（受付開始：12:45～）

◆場所：SAPジャパン 本社　セミナールーム

　　〒102-8022 東京都千代田区麹町1-6-4 SAPジャパンビル

　　http://www.sap.com/japan/tokyo

　　リモート接続をお申込の方には、インフォセッション前日までにリモート接続の方法をご連絡いたします。

◆アジェンダ：（予告なく変更する場合がございますのでご了承下さい）

12:45～　　　　受付開始

13:00～15:00　他社データベースから SQL Anywhereへ移行方法について

　　　　　　　- スキーマの移行について

　　　　　　　- SQL 変換について

　　　　　　　- データ移行について

◆受講対象者：(Non SAP ERP) システム営業、システムプリセールス担当者、

　　　　　　コンサルタント、システム開発者、データベース管理者

◆費用：無償

◆募集人数：50名（定員に達し次第締め切らせていただきます）

◆参加のお申込方法：

　　　　　　こちらへご連絡ください。

◆お知らせ：次回開催予定セッション内容

【SQL Anywhere 概要およびOracleからの移行事例紹介セミナー】

大阪：6月21日（火） 14:00-16:30　（受付開始：13:45）@SAPジャパン株式会社 西日本支社セミナールーム

福岡：7月 7日（木） 14:00-16:30　（受付開始：13:45）@福岡商工会議所

お申込みは、こちらより

＊内容は、5/11に東京で開催しましたものと同様になります。

ご好評につき、5/11に東京で開催した移行事例セミナーを以下の日程で大阪および福岡でも開催します。皆様のご参加をお待ちしております。

===

SQL Anywhere 概要およびOracleからの移行事例紹介セミナー

【開催概要】

<大阪>

日時：　　　　　2016年6月21日（火） 14:00 ～ 16:30　（受付開始：13:45）

場所：　　　　　SAPジャパン株式会社 西日本支社セミナールーム

　　　　　　　　　〒530-0001 大阪府大阪市北区梅田3-3-10 梅田ダイビル5Ｆ（受付）

<福岡>

日時：　　　　　2016年7月7日（木） 14:00 ～ 16:30　（受付開始：13:45）

場所：　　　　　福岡商工会議所

　　　　　　　　　〒812-0011 福岡県福岡市博多区博多駅前2-9-28

受講対象者：       製品企画、アプリケーション開発者、データベース管理者 システム営業、システムプリセールスご担当者、コンサルタント

費用：　　　　   無料

【アジェンダ】

1)　SQL Anywhere の概要、ライセンスと価格

2)　バイナル様事例

3)　SQL Anywhere機能詳細

       a)　SQL Anywhereスイートに含まれるコンポーネント

       b)　SQL Anywhereサーバー機能

           （自動管理、自動チューニング、HA、スケールアウト、アプリケーション埋め込み向け機能、他社データベースからのマイグレーション支援ツール）

       c)クラウド版 SQL Anywhere, on-demand edition

*予告なく変更する場合がございますのでご了承下さい

参加お申込みはこちらより

===