|
Blogs by

篤 浅野

  目的 このページの目的は、リレーショナル・データベースのデッドロックを特定して対処する方法について説明します。 概要 「デッドロック」とうい用語は、「サイクル・デッドロック」と呼ばれる状況を指しています。2つ以上の競合するトランザクションが同じリソース(通常、テーブルやローのロック)上で相互にブロックしているため、どのトランザクションも処理を進行できなくなり、サーバ側でいずれかのトランザクションを強制的に終了する必要がある状況です。 データベースのデッドロックを解決する方法として、状況に応じて2つの異なるアプローチが考えられます。それぞれのアプローチは、入手可能な情報、対応する側の経験または、嗜好に基づいています。データベース・スキーマの修正を好む管理者もいれば、SQLコードやサーバ/接続オプションの変更を優先する管理者もいます。 デッドロックの難しい点は、テスト環境やQA環境ではほとんど発生せず、開発サイクルの早期に発見することが困難であるということです。通常、デバッグは困難であり、状況によっては、コードの修正もできません。 データベースのデッドロックを回避するために、いくつかのことが必要です。 ・デッドロック情報をログに記録する ・関連するSQLの識別 ・パフォーマンスのためにクエリが最適化されていることを確認 ・トランザクションを短くする ・一般的なパフォーマンスを改訂する デッドロックは、データベース設計及び、SQLコーディングの貧弱さまたは、システムに隠れているその他の問題の症状であることを覚えておくことが重要です。 このドキュメントの例では、SQL Anywhereをデータベース・サーバとして使用していますが、基本的には、SAP HANA、SAP ASE、SAP IQ、Microsoft SQL Server、Oracleなどのその他のリレーショナル・データベース・システムにも同様の手法を適用できます。 アプリケーションがデッドロックの影響を受けているかどうか確認する方法 デッドロックは、散発的(一度起こった後、再び繰り返される)または、反復的(一日の特定の時間に、または特定のレポート/プロシージャ・コールの処理時)に発生する可能性があります。 データベース管理者は、無視するものと注意を払うものか判断する必要があります。 デッドロックが発生する理由は、アプリケーションとデータベース設計に絞り込むことが重要なポイントです。 アプリケーションが異常な動作をしている場合は、ほとんどの場合、処理が正常に実行されているが、何も変更されていないにもかかわらずトランザクションがロールバックされたり、スクリプト処理が失敗したり、アプリケーションから直接、次のエラーが返される場合: SQLCODE=-306, ODBC 3 State=”40001″ 簡単な分析を実行し、デッドロックの原因をデータベースで検証します。 デッドロック情報のロギング SAP SQL Anywhereには、ユーザがデッドロックを解決する上で必要な情報を入手できるデッドロック・ロギング機能があります。デッドロック・ロギング機能は、デフォルトでは有効になっていません。この機能を有効にするには、管理者がSybase

目的: このページの目的は、mlfiletransfer ユーティリティの使用方法を説明することです。リモート・データベースの集中管理機能の一部である、Mobile Link Agent を使用するファイル転送の代替方法についても説明します。 概要: Mobile Link 経由でファイルをアップロードまたは、ダウンロードするには、Mobile Link ファイル転送ユーティリティ(mlfiletransfer)を使用します。 リモート・デバイスを初めて作成するときや、リモート・デバイスでソフトウェアのアップグレードが必要なときに非常に便利です。 Mobile Link ファイル転送ユーティリティの使用 Mobile Link サーバの設定 mltransfer ユーティリティを使用するには、転送するファイルのルート・ディレクトリを指定するオプションを設定して Mobile Link サーバを構成する必要があります。 ユーティリティを使用してファイルをダウンロードする場合は、Mobile Link サーバを -ftr オプションで起動する必要があります。 このユーティリティを使用してファイルをアップロードする場合は、Mobile Link サーバを- ftru オプションで起動する必要があります。 Mobile

概要: この文章はODBCトレースの実行方法について説明します。 このトレースはトラブルシューティングのために役に立つかもしれません。 1. ODBC データソースアドミニストレーター(管理ツールフォルダ)に移動します。次の画面が表 示されます。 2.[トレース]タブをクリックします。次の画面が表示されます。 3.ログのデフォルト・パスは、ルート・ディレクトリです。必要に応じてログ ファイルのパスを 変更してから[トレースの開始] を押します。 4.この時点で接続に関する問題のデバッグが試行できるので、アプリケーションから接続します。 そして、障害が発生したら、アドミニストレーターに戻って、[トレースの停止] を押します。 5.ODBC のトレースは、ログ ファイルのパスで指定したsql.log ファイルに書き込まれます。 サポート部門から要求された場合は、現象発生時のsql.logを提供して下さい。 ご参考 ODBCトレースは、要求ログと同時に収集することでより詳細な調査が可能になります。 要求ロギング 要求ログは、SQL Anywhere がクライアントから受け付けた要求を出力します。

この文書では、サイレントインストールによる SQL Anywhere Express Bug Fix(EBF)の配備方法について説明します。 Windows プラットフォーム用 SQL Anywhere EBF は、PackageForTheWeb(PFTW)フォーマットを使用します。PFTW は、各タイプのインストールのコンテナです。PFTW は、自動的にインストールを開始します。 PFTW 実行可能ファイルに -s 引数を追加すると、PFTW がサイレントに実行されますが、パッケージに組み込まれているインストーラは、サイレントには起動されません。そのため、EBF のインストールをサイレントに実行することはできないように感じられます。PFTW を完全にサイレントにするには、組み込まれているインストーラもサイレント・モードで起動する必要があります。-a 引数に続くテキストは、PFTW が起動する実行可能ファイルに渡されます。そこで、この -a 引数を使用して、インストーラをサイレントに起動するためのコマンドラインを PFTW コマンドラインで渡します。 /S オプションは、初期化ダイアログを非表示にします。このオプションは /v とともに使用します。/v は、Microsoft Windows インストーラ・ツール Msiexec のパラメータを指定します。/qn は、MSI

目的 このページの目的は、データベースとサーバの名前の割り当て方法を明確にすることです。また、dbeng16コマンドと -nスイッチについても説明します。 概要 データベース・サーバ(データベース・エンジンとも呼ばれる)を起動すると、起動プロセスで必ず名前がサーバに与えられます。 -n コマンドライン・オプションを使用すると、サーバ・スイッチとしてサーバに名前を付けたり、データベース・スイッチとしてデータベースに名前を付けることができます。このスイッチの意味は、その位置によって異なります。サーバ名とデータベース名は、データベースに接続するときにクライアント・アプリケーションが使用する接続パラメータのひとつです。サーバ名は、デスクトップ・アイコンとサーバ・ウィンドウのタイトルバーに表示されます。 SQL Anywhere データベース・サーバの命名の重要性 各SAP SQL Anywhere データベース・システムには、データベースを管理するデータベース・サーバが必要となります。 他のアプリケーションがデータベース・ファイルを直接扱うことはなく、それらの各アプリケーションは、データベース・サーバを通じて通信します。そのため、データベースへの排他的な通信ポータルとしてサーバを扱う必要があるため、データベース・サーバへのアクセスなしでは、データベースにアクセスできません。 ネットワーク上の他のサーバ名と競合を回避する場合や、クライアント・アプリケーションのユーザに意味のある名前を提供する場合に、データベース・サーバ名を指定するができます。サーバが存続している間(つまりシャットダウンされるまで)は指定された名前を維持します。 データベース・サーバ名の割り当て方法 最初のデータベース・ファイルの前に -n データベースサーバ・スイッチを指定することによって、サーバに名前を付けることができます。 例えば、次のコマンド・ラインでは、マウントされた demo データベースを使ってサーバが起動され、そのサーバに Test という名前が付けられます。 dbeng16 -n Test demo.db データベースを指定せずにデータベース・サーバを起動する場合は、サーバに直接名前を付ける必要があります。次のコマンドを実行すると、データベースを起動せずに Test という名前のサーバを起動します。 dbeng16 -n Test

目的 このページの目的は、暗号化の基礎とSQL Anywhere 10以降のデータベースに対してテーブルの暗号化を構成する方法を説明します。   概要 暗号化は、情報の閲覧を許可されていないユーザから情報を保護するために使用するセキュリティ・ツールです。SQL Anywhereはバージョン8.0.0で強力な暗号化が採用されました。 バージョン10以降では、データベース全体または、選択したテーブルのみを暗号化することができます。 これにより更に柔軟性が向上し、データベースの一部のみを暗号化する必要がある暗号化ユーザのためにパフォーマンスを高めることができます。   暗号化は、情報の閲覧を許可されていないユーザに対して、その情報の解読を困難にするプロセスです。暗号化されたデータベース・ファイルに物理的にアクセスできても、ファイルを分析したり、データベースに含まれるデータを表示することはできません。   暗号化には2種類のタイプがあります:単純暗号化と強力な暗号化です。 単純暗号化は、データを難読化しますが、暗号化キーを使用していません。ディスク・ユーティリティを使用して権限のないユーザがデータを見ることを防止する簡単な方法です。 強力暗号化は、暗号化アルゴリズムを使用してデータを暗号化し、キーを持つユーザのみにアクセスを許可します。   暗号化方式とは、情報の暗号化と復号化に使用するアルゴリズムです。暗号化方式を使用して、読みやすいプレーン・テキストを人間には判読不能な暗号文に変換します。ブロック暗号は、プレーン・テキストのブロックを暗号文のブロックに変換します。ブロックとは、固定バイト数のテキストの集合です。   SQL Anywhere暗号化の概要 SQL Anywhere 10 は、強力暗号化のためにAES暗号化を実装しています。アルゴリズムは、ラインダール(Rijndael)と呼ばれ、米国政府により次世代標準暗号化方式として選択されています。   AES-FIPS暗号化は、SQL Anywhereで特定のプラットフォームで利用可能です。AES-FIPSは、基本的にAESと同じです。唯一の違いは、AES-FIPSでは、Certicomによって提供された実装を使用していることです。この実装は、FIPS規格に準拠して米国政府の承認を得ています。FIPSは、Federal Information Processing Standard(連邦情報処理標準)の略語です。 SQL Anywhere 10 では、データベースのページサイズと同じサイズのブロックが使用されます。また、SQL

目的 このページの目的は、SQL Anywhereデータベースを再構築する時に照合とコードページの変更方法を説明することです。   はじめに この文書で使用されている例では、元のデータベースは、OEM照合(コードページ850)を使用し、再構築したデータベースは、ANSI照合を使用しています。 いくつかの例では、ANSIクライアント(例えば変換のない Windows ODBCクライアント)のOEMコードページを使用してデータベースからデータを取得するときにドイツ語のウムラウトのようなアクセント付き文字は、正しく表示されません。   コードページ 850に基づくOEM照合で構築されたデータベースがあるとします。(C:\oem.db)   説明 1.文字セット変換をオフにしてデータベースを起動します。     dbeng17 -ct- c:\oem.db     注意:SQL Anywhere(Adaptive Server Anywhere)バージョン8以降では、文字セット変換はデフォルトでオンになっており、-ct-オプションを省略することができます。   2.内部アンロードと外部アンロードを使用してデータベースをアンロードします。ここで生成された reload.sqlファイルは、LOAD TABLE文の代わりにINPUT INTO文を持つことを意味します。    LOAD TABLE は、サーバをデータ変換しません。必要があれば、INPUT

目的 このドキュメントの目的は、Mobile Link同期プロファイルの作成方法及び、使われ方を議論します。   概要 同期プロファイルは、SQL Anywhere 及び、Ultra Light の同期オプションをリモート・データベースに保存できる SQL Anywhere の機能です。 この機能を使用すれば、リモート・データベースの同期を開始するときに使用するコマンド・ラインや文の複雑さを軽減することができます。また、同期構成をアプリケーションではなくデータベース内に配置することもできます。 データベース内に同期情報を格納すれば、情報を更新するために新たなアプリケーションを配備する必要がなく、データベースを更新するだけで済むため、アプリケーションに格納するよりも便利です。   同期プロファイルは、SQL Anywhere クライアント (dbmlsync) または Ultra Light の SYNCHRONIZE 文を呼び出すときか、または Dbmlsync API から同期を起動するときに指定することができます。同期プロファイルは、作成した後に削除したり変更することができます。   同期プロファイルの作成 Mobile Link クライアント用の同期プロファイルを作成するには、以下の構文を使用します:  

目的 このドキュメントは、SQL Anywhere OPENXML 関数を使用して、特殊文字が含まれている可能性のある文字列ノード要素を扱っているユーザを対象としています。   概要 SQL Anywhere の OPENXML 関数で使用される XML 解析メカニズムは、いくつかの特殊文字を文字列ノード内のリテラル文字として処理しませんが、代わりに、そのノードを分割します。これらの文字は、&quot;(引用符)、&amp;(アンパサンド)、&lt;(< 文字)と &gt;(> 文字)が含まれます。   例1 SELECT * FROM OPENXML( ‘<products> <prod_type id=”301″>Tee Shirt</prod_type> <prod_type id=”401″>Baseball Cap</prod_type> </products>’, ‘/products/prod_type’ ) WITH (

概要 サーバとは別マシン上にあるデータベース・ファイルを使用して、SQL Anywhere サーバにアクセスすることは可能ですが、すべての状況で可能ではありません。以下に、SQL Anywhere データベースの用途に検討する可能性があるアーキテクチャーのいくつかを記載します。     インターネットSCSI(iSCSI)/ストレージ・エリア・ネットワーク(SAN)/ネットワーク・アタッチド・ストレージ(NAS) iSCSI、SAN 及び NAS のハードウェア・ソフトウェアのベンダーについて、SQL Anywhere が正常に機能するかどうかを決定する2つの主要な要件があります: ファイル書き込みの順番が保障されていること。 これは、もしサーバが A の書き込みをリクエストし、その後に B の書き込みをリクエストした場合、B が書き込まれる前に A が物理メディアに書き込まれることを SAN 及び NAS が保証していることを意味します。 さらに Windows では、FlushFileBuffers() の後のSetEndOfFile() コールが、ファイルのメタデータを物理メディアに書き込むのに余裕があることをマイクロソフトが保証することも意味します。 我々は、それらと同じ動作が iSCSI、