SQL Server ミラーリング

SQL Server ミラーリングについて、サーバー間の通信を設定する概念を書いておきます。

まず、（A)発信側サーバーでの処理
１．マスターキーを作る（パスワードを設定）
　　CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'pass';
　　という感じ。
２．証明書を作成する。
　　CREATE CERTIFICATE　～
３．エンドポイントを作成する。（エンドポイントには２の証明書が関連付けする）
　　CREATE ENDPOINT Endpoint_Mirroring
     STATE = STARTED
     AS TCP (
      LISTENER_PORT=●●●●
      , LISTENER_IP = ALL
     )
     FOR DATABASE_MIRRORING (
        AUTHENTICATION = CERTIFICATE 証明書名
       , ENCRYPTION = REQUIRED ALGORITHM AES
       , ROLE = ALL
   );
このALGORITHMの「AES」の部分はサーバー全てで同じでなければならないらしい(?)
ミラーリング用のエンドポイントは一つしか作れないので、送受信の相互にこのエンドポイントを使う事になるのだと思います。このため、暗号化のアルゴリズムが同じ無ければならないのだと思いますが、本当なら送受信で別々のエンドポイントを作れるようにしておいた方がスマートだと思いますが、どうでしょうか？
何か理由があるのだと思いますが、どうもこの辺りの設計思想が分かりにくくて、設定時に悩んでしまいます。


４．証明書をファイルに書き出して、それを受信側サーバーに移しておく。

次に（B)受信サーバー側での処理です。
１．ログインを作成する（パスワードを設定）。
２．そのログイン に対してユーザーを作る。
３．発信側の証明書ファイルからログイン用の証明書を作る。
　　その時に２のユーザーに関連付けしておく。
４．エンドポイントにログインをGRANTしておく。

以上にて通信が行えるようになるはずです。
監視サーバーを設置する場合は、プリンシパル、ミラー、監視のそれぞれで相互に通信できるようにしなければなりませんので、以上のような処理をそれぞれのサーバーで行う事になります。

SQL Server ネタを

ミラーリング構成で、サーバー機の故障により再度ミラー構成にした時に手間取ったので、備忘録として書いておきます。

1. エンドポイントの状況を見るSQL
   SELECT * FROM sys.database_mirroring_endpoints ;
   ここで、encryption_algorithmが異なっていると通信できないとの事。
   
2.  certificateを調べるSQL
   SELECT * FROM sys.certificates;
   
3. ミラーリングの状態を見る
   SELECT
       DB_NAME(database_id) AS 'DatabaseName',
       mirroring_role_desc,
       mirroring_safety_level_desc,
       mirroring_state_desc,
       mirroring_safety_sequence,
       mirroring_role_sequence,
       mirroring_partner_instance,
       mirroring_witness_name,
       mirroring_witness_state_desc,
       mirroring_failover_lsn
   FROM sys.database_mirroring
   WHERE mirroring_guid IS NOT NULL;
   
4. エンドポイントのアクセス権を見る
   SELECT 'Metadata Check';
   SELECT EP.name, SP.STATE,
      CONVERT(nvarchar(38), suser_name(SP.grantor_principal_id))
         AS GRANTOR,
      SP.TYPE AS PERMISSION,
      CONVERT(nvarchar(46),suser_name(SP.grantee_principal_id))
         AS GRANTEE
      FROM sys.server_permissions SP , sys.endpoints EP
      WHERE SP.major_id = EP.endpoint_id
      ORDER BY Permission,grantor, grantee;
   GO

Access2013でadp廃止！

Access2013でadpファイル形式が廃止されたようです。

adpファイルとはAccess プロジェクトファイルで、ローカルにデータを保存するのでは無く、SQL Server等に接続して使うクライアント－サーバーシステムを構築するのに非常に便利な機能だったのですが、何の予告も無く急に廃止となってしまいました。

恐らく世界中で業務システムにこのadpファイルが使われているので、この廃止の影響は甚大だと思います。

新しい端末を導入する場合、OSが最新になりますのでその上で稼動するアプリケーションも古いものは動かなくなります。このため、adpファイルもそれを扱う事ができるアプリケーションが最新端末では動かないという事になり、新しい端末用のアプリケーションを新たに作らなければなりません。

つまり、今まで作ってきて運用してきたアプリケーションを全て見直す事になってしまい、その工数は大変な量になると容易に予想されます。

一企業のソフトを使っている限りこのような事になるリスクは発生しますが、このような事が繰り返されると信用を失いますよね～。

SQL Serverのデタッチ

今回はMicrosoftのSQL Serverのネタを一つ。
備忘録として書いておきます。

MicrosoftのSQL Serverでデータベースを一度デタッチすると、TRUSTWORTHYプロパティがFalseとなってしまいます。
これによって、CLR関数等にて .NET Frameworkのエラーが発生します。

これを対策するには、再アタッチした後に、
ALTER DATABASE xxxDB SET TRUSTWORTHY ON;
としてTRUSTWORTHYプロパティをTrueに変更する必要があります。

Microsoftのソフトは何とも面倒ですし、ドキュメントが理解不能です(´ω｀。)

iPhone 5 Optimization Requirement

今度はiPhone用アプリをiTunes Storeに登録する時に苦労(´ω｀。)

その顛末を記録です。

iTunesにアプリを登録すると以下のようなメールがiTunes Storeから来ました。

iPhone 5 Optimization Requirement - Your binary is not optimized for iPhone 5. As of May 1, all new iPhone apps and app updates submitted must support the 4-inch display on iPhone 5. All apps must include a launch image of the appropriate size. Learn more about iPhone 5 support by reviewing the iOS Human Interface Guidelines.

特にiPhone5の画面表示では問題無く作っていると思っていたのですが、よく読むと launch imageが必要との事。

今回はAIR for mobileのアプリでFlash Builderにて作成しています。このため、スプラッシュ画面の作成は Flash Builderの機能を使って適当な画像サイズの画像を起動画面に表示するように変更しました。そして再度アップロードしたところ状況は全く改善せず(´ω｀。)

いろいろ検索してみると、どうも launch imageにDefault-568h@2x.pngという画像が必要なようです。先ほど記載したように今回はFlash Builderにてスプラッシュ画面を作成していますので、この画像がアプリパッケージに含まれているのかどうか分かりません。（後でipaファイルの拡張子をzipに変更すればフォルダに展開できる事を知りましたが。。。）そこでとりあえずこのDefault-568h@2x.pngという画像を指定サイズ通りに作成して、srcディレクトリ直下に配置し、ビルドの際にこの画像も含めるように指定して再ビルドしてアップロードしてみました。
（この後に Default@2x.png画像も加えましたが、これは最終的に必要かどうか分かりません）

すると今度は次のようなメールが。

iPhone 5 Optimization Requirement - Your binary is not optimized for iPhone 5. As of May 1, all new iPhone apps and app updates submitted must support the 4-inch display on iPhone 5. All apps must include a launch image of the appropriate size. Learn more about iPhone 5 support by reviewing the iOS Human Interface Guidelines.

Invalid Launch Image - Your app contains a launch image with a size modifier that is only supported for apps built with the iOS 6.0 SDK or later.

う～ん、少しは状況が改善しているのか、していないのか。。。。

iOS 6.0 SDK以降を使えと言われても、FlashBuilderで作ってるし。。。
と、言うわけで今度はFlash BuilderのSDKを調査する事に。

使っていたFlash BuilderのSDKはFlex 4.6.0でした。これより新しいものはAdobeからはリリースされていないようです。Flash Builderのインストールフォルダの中のsdksを覗いてみると4.6.0というフォルダがありその中にはAIR SDK Readme.txtがありこれを見ると「Adobe AIR 3.1 SDK」となっています。 Adobe AIR SDKの最新版は3.7ですので、これを適用できないかと考えました。そこでググルとありました。

「Flash Biulder 4.7に AIR SDK 3.5 をインストールする手順」

http://maccle.com/air_flex/how-to-install-air-sdk-3-5-to-flash-builder-4-7-with-flex-sdk-4-6-0-on-mac/

 この方法を用いて再ビルドしてアップロードしたところ、「Your app status is Waiting For Review」というメールがやっと来ました。ふ～っ

ところが、 次のメールも

Dear developer,

We have discovered one or more issues with your recent delivery for "○○○○". Your delivery was successful, but you may wish to correct the following issues in your next delivery:

Non-PIE Binary - The executable '○○○○.app' is not a Position Independent Executable. Please ensure that your build settings are configured to create PIE executables.

If you would like to update your binary for this app, you can reject this binary from the Binary Details page in iTunes Connect. Note that rejecting your binary will remove your app from the review queue and the review process will start over from the beginning when you resubmit your binary.

Regards,

う～ん、またまたどうすればいいのやら。とりあえずこのままで :-)

iOS用アプリのAd Hoc インストール失敗

iOS用アプリをFlash Builderで作成していたのですが、試験用端末にAd Hocインストールする時に何度も失敗して苦労したので、その時の状況を記録します。

今まで開発にWindowsを使っていたのですが、それを今回Mac Book Proに変更しました。これは外出先でもiPhoneにインストール作業ができるようにと考えたからです。

このため、Windows機からソース一式、アプリ本体、Provisioning Profilesをコピーしてきてインストール作業を行いましたがことごとく失敗

iOS Developer CenterからProvisioning Profilesを再ダウンロードしてもダメで、もちろんProvisioning Profilesにインストールしようとしている端末のUDIDが登録されていることも確認していました。

ここで「ひょっとして、CertificatesというものはPCを認証するためのものでは？」という事に気付きCertificatesの作成から新たに行いました。そして、そのCertificatesを使って再度Provisioning Profilesを新規作成してそこにもう一度インストールする端末を登録してダウンロード。これとp12証明書を用いて再度ビルドしてそれをiTunesにコピーしてインストールすると無事に完了しました　

う～ん、いちいち面倒だ～！

iOS用アプリのProvisioning Profilesについて

この前からFlashBuilderを使って、iOS用アプリを作成しているのですが、試験用端末にAdHocインストールするのに手間取ったのでその時の内容を記載しておきます。

インストールしたい端末をUSB接続してiTunesを起動してその端末のUDIDをコピー、そしてApple DeveloperサイトにてiOS Devicesの登録をするまでは問題無いと思いますが、この端末にインストールするには、用意したProvisioning Profilesを編集して、Devicesの欄でこの端末をチェックして、それをダウンロードして使わなければいけません。

Provisioning Profilesの編集項目として、Certificates欄もありここも複数あれば選択できるようになっていますので、インストールする端末が変更となればこれも変更する必要があるようです。

CertificatesやProvisioning Profilesが何のためのものなのか、最初は分かり難いため試行錯誤が続きます(´ω｀。)