#Caché

これは、InterSystems FAQサイトの記事です。

SELECT ... FOR UPDATE は明示的な行ロック取得の方法として多くの RDBMS で実装されているため、この機能を使われているケースも多いと思います。

このシンタックスは InterSystems 製品ではエラーにはなりませんが、期待されるような行ロックの取得は行われません。

この記事では同等の機能を実現する方法をご紹介します。

DECLARE CURSOR C1 IS
SELECT Name FROM Person WHERE Name LIKE 'A%' FOR UPDATE
OPEN C1
LOOP FETCH C1 INTO name　
... name を表示
... 終了ならLOOPをEXIT
END LOOP
CLOSE C1

上記のようなSQL文は、下記のSQL文で代替可能です。

※下記2行目のUPDATE文の実行により対象行に対して排他ロックがかかるため、他DBの動作と異なる点ご注意ください。

最近行われたディスカッションの中で、Caché ObjectScript における for/while loop のパフォーマンンスが話に出ましたので、意見やベストプラクティスをコミュニティの皆さんと共有したいと思います。 これ自体が基本的なトピックではありますが、他の点では合理的と言える方法のパフォーマンスが意味する内容を見逃してしまうことがよくあります。 つまり、$ListNext を使って$ListBuild リストをイテレートするループ、または $Order を使ってローカル配列をイテレートするループが最も高速な選択肢ということです。

これはInterSystems FAQ サイトの記事です。

この記事では「グローバルを誤って削除してしまった！」という場合の対処方法をご紹介します。

誤って削除してしまった特定のグローバルを復旧するためには、バックアップファイルとジャーナルを使用します。
復旧は、^ZJRNFILTユーティリティによるジャーナルリストアで条件を指定してジャーナルレコードをリストアする方法で行います。
この方法で、ある時点のデータベースのバックアップに対して、削除が含まれるジャーナルレコードについて特定グローバルを削除するまでのものを適用することができます。

^ZJRNFILTユーティリティの詳細については、以下のドキュメントをご参照ください。

CachéとCosFakerを使ったテスト駆動開発の簡単な紹介

読了****目安時間: 6分

皆さん、こんにちは。

私がTDDに初めて出会ったのは約9年前のことです。すぐに夢中になってしまいました。
最近は非常に人気が出てきているようですが、残念ながら多くの企業ではあまり使われていないようです。 また、主に初心者の方ではありますが、一体それがなんであるのか、どのように使うのかといったことさえも知らない開発者もたくさんいます。

Config.Configurationクラス、SYS.Databaseクラスのメソッドを使用して、ネームスペース・データベースの作成及び登録をターミナルから実行することができます。

以下はデータベースファル/CacheDB/AAA/cache.datを作成し、構成ファイル（cache.cpf）にデータベース AAA、及び、ネームスペースAAAの登録を行う一連の実行例です。 ＊実行は、%SYSネームスペースで行って下さい。＊

大きなサイズのデータを持つフィールドに対してインデックスを作成すると、<SUBSCRIPT>エラーとなることがあります。

これは、グローバルの添え字（サブスクリプト）のサイズには制限があり、制限を超えるとエラーとなるためです。

例えば、以下のようなインデックスの場合、

^Sample.PersonI("NameIdx"," xxx...xxx",1)       =       ""

グローバル名＋サブスクリプト部（＝の左側）が、エンコード文字数で最長 511 文字を超えるとエラーとなります（日本語の場合はもっと小さな文字数です）。

※ご参考：グローバル参照の最大長

これは InterSystems FAQ サイトの記事です。

インスタンスの開始が失敗し、コンソールログに"There exists a MISMATCH.WIJ file"が記録されている場合、何らかのシステム障害の影響でデータベースの整合性に関して問題が生じていることを示しています。

このような状況が発生した際にインスタンスの開始ができるようにするためには、以下の手順を実施します。

(1) a. インスタンスをNOSTUモードで起動
(2) b. データベースの整合性チェック

◆(2)の整合性チェックでエラーを検出しなかった場合、
　(3) d. MISMATCH.WIJ ファイルのリネーム
　(4) e. インスタンスの再起動
を実施します。

InterSystems は、より新しく優れたオプションが利用可能になったときに従来のテクノロジーの開発を中止することがあります。
ただし、それら機能は最小サポートバージョン以後の製品であれば他の機能と同等にサポートします。

InterSystems IRISのSQLの性能を評価する簡単なベンチマークテストを公開します。

また、このベンチマークプログラムで測定した過去の様々なハードウェアでのベンチマーク結果も公開します。

ハードウェアの進歩、インターシステムズの新しいテクノロジーの追加や性能改善によって、性能が劇的に変化しています。

現在のハードウェアの性能を考慮すると、少し物足りない感じが否めないですが、過去との結果の公正な比較という意味であえて、データの規模に関しては過去と同一条件でベンチマーク実施した結果となっています。

データの規模に関してはデータ件数を増やすことで変更できるようになっています。（現時点では500万件）

またこのベンチマークプログラムはインターシステムズ製品用に実装されていますが、使用しているテーブル構造は比較的シンプルなもので、また使用しているSQL文も標準的なものなので、他データベースシステムでも同じベンチマークを実施することはそんなに困難ではありません。

ベンチマークプログラムのリポジトリ

これは InterSystems FAQ サイトの記事です。

SQLのINSERT/UPDATE/DELETE文で大量のデータを更新する際に、高速化する方法をご紹介します。
以下の2つの手順を実行することで、更新処理のパフォーマンスを向上させることが可能です。

１．INSERT/UPDATE/DELETE時にインデックスを作成せず、あとでまとめて作成する

２．INSERT/UPDATE/DELETE時にジャーナルをOFFにする

１は、%NOINDEX キーワードを指定してインデックスの生成を後でまとめて行うことで、インデックスの構築を抑制しパフォーマンスを向上させる方法です。

クエリ実行例は、以下のようになります。

これは InterSystems FAQ サイトの記事です。

新しいインデックスを定義した後、インデックスの再構築が完了する前にクエリを実行するとデータが存在しているにもかかわらず「検索結果0件」や検索結果数が徐々に増えるような状況が発生します。

インデックスを永続クラス定義（またはテーブル定義）に追加しコンパイルすることで今まで使用していたクエリ実行経路が削除され、再度同じクエリを実行するタイミングで新しいインデックス定義を含めた実行経路が作成されるためです。（この時にインデックス再構築が完了していないとインデックスデータが存在しない、または不完全であるため0件や徐々に検索結果数が増えるような状況を起こします。）

これを起こさなために、新しいインデックスの再構築が終了するまでクエリオプティマイザにインデックスを使用させないように指定する方法が用意されています。

※インデックスの再構築が完了したら、必ず指定を元に戻してください。

DeepSee で階層を設計する場合、子メンバーに 1 つの親しか指定できません。 子が 2 つの親に対応する場合には、信頼性のない結果が得られることになります。 類似する 2 つのメンバーが存在する場合、そのキーがそれぞれ一意になるように変更する必要があります。 これが起きる場合とそれを回避する方法について、2 つの例を見ながら説明します。

例 1

（アメリカには）Boston と言う都市がある州がたくさんあります。 私のサンプルデータでは、Boston, MA（マサチューセッツ州ボストン）と Boston, NY（ニューヨーク州ボストン）のレコードがあります。 次元は次のように定義されています。

四半期ごとにお届けしてきたプラットフォーム最新情報ですが、今回が今年最後になりました。 みなさまのおかげで、素晴らしい初年度となりました。ありがとうございました。今回は、ミニマムサポート CPU リスト、AIX における OpenSSL 3.0 サポート、その他もろもろをお届けします。また 2024 年にお会いしましょう！