Microsoft SQL Server を使用したサブスクリプションデータの保存
注:
このドキュメントは、MS SQL Server および T-SQL クエリに関する基本的な知識があることを前提としています。管理者は、このドキュメントに従う前に、SQL Server の構成、使用、および管理に習熟している必要があります。
はじめに
ESENT は、Windows が使用できる組み込みのトランザクションデータベースエンジンです。StoreFront のすべてのバージョンは、デフォルトで組み込みの ESENT データベースの使用をサポートしています。ストアが SQL 接続文字列を使用するように構成されている場合、Microsoft SQL Server インスタンスに接続することもできます。
StoreFront を ESENT から SQL の使用に切り替える主な利点は、T-SQL 更新ステートメントによってサブスクリプションレコードを管理、変更、または削除できることです。SQL を使用する場合、サブスクリプションデータに軽微な変更が行われるたびに、ESENT サブスクリプションデータ全体をエクスポート、変更、再インポートする必要はありません。
既存のサブスクリプションデータを ESENT から Microsoft SQL Server に移行するには、StoreFront からエクスポートされたフラットな ESENT データを、一括インポートに適した SQL フレンドリーな形式に変換する必要があります。新しいサブスクリプションデータがない新規展開の場合、この手順は不要です。データ変換手順は一度だけ必要です。この記事では、記事で参照されている -STF PowerShell SDK を導入したバージョン 3.5 以降のすべての StoreFront バージョンで使用できるサポートされている構成について説明します。
注:
ネットワーク障害により、StoreFront がサブスクリプションデータを保存するために使用する SQL Server インスタンスへの接続に失敗しても、StoreFront の展開が使用不能になることはありません。障害は一時的にユーザーエクスペリエンスを低下させるだけであり、SQL Server への接続が復元されるまで、ユーザーはお気に入りのリソースを追加、削除、または表示できません。障害発生中もリソースは列挙および起動できます。予期される動作は、ESENT を使用中に Citrix Subscription Store サービスが停止した場合と同じです。
ヒント:
KEYWORDS:Auto または KEYWORDS:Mandatory で構成されたリソースは、ESENT と SQL の両方を使用する場合でも同じように動作します。ユーザーのリソースにいずれかのキーワードが含まれている場合、ユーザーが最初にログオンしたときに新しい SQL サブスクリプションレコードが自動的に作成されます。
ESENT と SQL Server の利点
| ESENT | SQL |
|---|---|
| デフォルトであり、StoreFront を「すぐに使える」状態で使用するために追加の構成は不要です | はるかに管理しやすく、T-SQL クエリを使用してサブスクリプションデータを簡単に操作または更新できます。ユーザーごとのレコードの削除または更新を許可します。アプリケーション、デリバリーコントローラー、またはユーザーごとのレコードを簡単にカウントできます。会社/組織を離れたユーザーの不要なユーザーデータを簡単に削除できます。管理者がアグリゲーションの使用に切り替えたり、新しいデリバリーコントローラーがプロビジョニングされたりした場合など、デリバリーコントローラーの参照を簡単に更新できます |
| サブスクリプションの同期とプルスケジュールを使用して、異なるサーバーグループ間のレプリケーションを構成するのがより簡単です。 サブスクリプションの同期の構成を参照してください | StoreFront から分離されているため、データは別の SQL Server で管理されるため、StoreFront のアップグレード前にサブスクリプションデータをバックアップする必要がありません。サブスクリプションのバックアップは StoreFront とは独立しており、SQL のバックアップ戦略とメカニズムを使用します |
| サブスクリプション管理が不要な場合、SQL は不要です。サブスクリプションデータが更新される必要がない場合、ESENT は顧客のニーズを満たす可能性が高いです | サーバーグループのすべてのメンバーで共有されるサブスクリプションデータの単一コピーであるため、サーバー間のデータ差異やデータ同期の問題が発生する可能性が低くなります |
ESENT と SQL Server の欠点
| ESENT | SQL |
|---|---|
| サブスクリプションデータを簡単かつきめ細かく管理する簡単な手段がありません。サブスクリプションの操作は、エクスポートされた .txt ファイルで行う必要があります。サブスクリプションデータベース全体をエクスポートして再インポートする必要があります。検索と置換の技術を使用して、数千ものレコードを変更する必要がある場合があり、これは手間がかかり、エラーが発生しやすい可能性があります | 基本的な SQL の専門知識とインフラストラクチャが必要です。SQL ライセンスの購入が必要になる場合があり、StoreFront 展開の総所有コストが増加します。ただし、Citrix Virtual Apps and Desktops データベースインスタンスを StoreFront と共有してコストを削減することもできます |
| サーバーグループ内の各 StoreFront サーバーで ESENT データベースのコピーを維持する必要があります。まれに、このデータベースがサーバーグループ内または異なるサーバーグループ間で同期がずれることがあります | サーバーグループ間のサブスクリプションデータのレプリケーションは、簡単な展開タスクではありません。データセンターごとに複数の SQL インスタンスと、それら間のトランザクションレプリケーションが必要です。これには、専門的な MS SQL の専門知識が必要です |
| ESENT からのデータ移行と、SQL フレンドリーな形式への変換が必要です。このプロセスは一度だけ必要です | |
| 追加の Windows Server とライセンスが必要になる場合があります | |
| StoreFront を展開するための追加の手順が必要です |
展開シナリオ
注:
ユーザーサブスクリプションをサポートする場合、StoreFront 内で構成された各ストアには、ESENT データベースまたは Microsoft SQL データベースのいずれかが必要です。サブスクリプションデータの保存方法は、StoreFront 内のストアレベルで設定されます。
Citrix® は、管理の複雑さを軽減し、誤構成の範囲を縮小するために、すべてのストアデータベースが同じ Microsoft SQL Server インスタンスに配置されることを推奨しています。
複数のストアが同じデータベースを共有できますが、それらがすべて同じ接続文字列を使用するように構成されている必要があります。異なるデリバリーコントローラーを使用しているかどうかは関係ありません。複数のストアがデータベースを共有することの欠点は、各サブスクリプションレコードがどのストアに対応しているかを判別する方法がないことです。
複数のストアを持つ単一の StoreFront 展開で、2つのデータストレージ方法を組み合わせることは技術的に可能です。1つのストアを ESENT を使用するように構成し、別のストアを SQL を使用するように構成することも可能です。管理の複雑さが増し、誤構成の範囲が広がるため、これは推奨されません。
SQL Server にサブスクリプションデータを保存するために使用できるシナリオは4つあります。
シナリオ 1: ESENT を使用する単一の StoreFront サーバーまたはサーバーグループ (デフォルト)
デフォルトでは、バージョン 2.0 以降の StoreFront のすべてのバージョンは、フラットな ESENT データベースを使用して、サーバーグループのメンバー間でサブスクリプションデータを保存およびレプリケートします。サーバーグループの各メンバーは、サブスクリプションデータベースの同一のコピーを維持し、これはサーバーグループの他のすべてのメンバーと同期されます。このシナリオでは、追加の構成手順は不要です。このシナリオは、デリバリーコントローラー名の頻繁な変更を想定しない、または古いユーザーサブスクリプションの削除や更新などのサブスクリプションデータに対する頻繁な管理タスクを実行する必要がないほとんどの顧客に適しています。
シナリオ 2: 単一の StoreFront サーバーとローカルにインストールされた Microsoft SQL Server インスタンス
StoreFront はローカルにインストールされた SQL Server インスタンスを使用し、両方のコンポーネントは同じサーバー上に存在します。このシナリオは、顧客がデリバリーコントローラー名の頻繁な変更を行う必要がある場合、または古いユーザーサブスクリプションの削除や更新などのサブスクリプションデータに対する頻繁な管理タスクを実行する必要があるが、高可用性 StoreFront 展開を必要としない、単純な単一 StoreFront 展開に適しています。Citrix は、Microsoft SQL データベースインスタンスをホストするサーバーグループメンバーに単一障害点を作成するため、サーバーグループに対してこのシナリオを推奨しません。このシナリオは、大規模なエンタープライズ展開には適していません。
シナリオ 3: 高可用性用に構成された StoreFront サーバーグループと専用の Microsoft SQL Server インスタンス (推奨)
すべての StoreFront サーバーグループメンバーは、同じ専用の Microsoft SQL Server インスタンスまたは SQL フェールオーバークラスターに接続します。これは、Citrix 管理者がデリバリーコントローラー名の頻繁な変更を行いたい場合、または古いユーザーサブスクリプションの削除や更新などのサブスクリプションデータに対する頻繁な管理タスクを実行したい場合で、高可用性を必要とする大規模なエンタープライズ展開に最も適したモデルです。
シナリオ 4: 複数の StoreFront サーバーグループと、サーバーグループごとに各データセンターに専用の Microsoft SQL Server インスタンス
注:
これは高度な構成です。トランザクションレプリケーションに精通した経験豊富な SQL Server 管理者であり、正常に展開するために必要なスキルを持っている場合にのみ試してください。
これはシナリオ 3 と同じですが、異なるリモートデータセンターで複数の StoreFront サーバーグループが必要な状況に拡張されます。Citrix 管理者は、同じまたは異なるデータセンター内の異なるサーバーグループ間でサブスクリプションデータを同期することを選択できます。データセンター内の各サーバーグループは、冗長性、フェールオーバー、およびパフォーマンスのために、独自の専用 Microsoft SQL Server インスタンスに接続します。このシナリオには、かなりの追加の Microsoft SQL Server 構成とインフラストラクチャが必要です。サブスクリプションデータとその SQL トランザクションをレプリケートするために、Microsoft SQL テクノロジーに完全に依存しています。
リソース
以下のスクリプトは、https://github.com/citrix/sample-scripts/tree/master/storefront からダウンロードして利用できます。
構成スクリプト
-
Set-STFDatabase.ps1 – 各ストアの MS SQL 接続文字列を設定します。StoreFront サーバーで実行します。
-
Add-LocalAppPoolAccounts.ps1 – ローカルの StoreFront サーバーのアプリプールに SQL データベースへの読み取り/書き込みアクセス権を付与します。シナリオ 2 の場合は SQL Server で実行します。
-
Add-RemoteSFAccounts.ps1 – サーバーグループ内のすべての StoreFront サーバーに SQL データベースへの読み取り/書き込みアクセス権を付与します。シナリオ 3 の場合は SQL Server で実行します。
-
Create-StoreSubscriptionsDB-2016.sql – SQL データベースとスキーマを作成します。SQL Server で実行します。
データ変換およびインポートスクリプト
-
Transform-SubscriptionDataForStore.ps1 – ESENT 内の既存のサブスクリプションデータをエクスポートし、インポートに適した SQL フレンドリーな形式に変換します。
-
Create-ImportSubscriptionDataSP.sql – Transform-SubscriptionDataForStore.ps1 によって変換されたデータをインポートするためのストアドプロシージャを作成します。Create-StoreSubscriptionsDB-2016.sql を使用してデータベーススキーマを作成した後、このスクリプトを SQL Server で一度実行します。
SQL Server での StoreFront サーバーのローカルセキュリティグループの構成
シナリオ 2: 単一の StoreFront サーバーとローカルにインストールされた Microsoft SQL Server インスタンス
Microsoft SQL Server 上に <SQLServer>\StoreFrontServers という名前のローカルセキュリティグループを作成し、IIS APPPOOL\DefaultAppPool および IIS APPPOOL\Citrix Receiver for Web の仮想アカウントを追加して、ローカルにインストールされた StoreFront が SQL に読み書きできるようにします。このセキュリティグループは、ストアサブスクリプションデータベーススキーマを作成する .SQL スクリプトで参照されるため、グループ名が一致していることを確認してください。
スクリプト Add-LocalAppPoolAccounts.ps1 をダウンロードして利用できます。
Add-LocalAppPoolAccounts.ps1 スクリプトを実行する前に StoreFront をインストールしてください。このスクリプトは、IIS APPPOOL\Citrix Receiver for Web 仮想 IIS アカウントを特定する機能に依存しており、このアカウントは StoreFront がインストールおよび構成されるまで存在しません。IIS APPPOOL\DefaultAppPool は、IIS Web サーバーの役割をインストールすることで自動的に作成されます。
# Create Local Group for StoreFront servers on DB Server
$LocalGroupName = "StoreFrontServers"
$Description = "Contains StoreFront Server Machine Accounts or StoreFront AppPool Virtual Accounts"
# Check whether the Local Group Exists
if ([ADSI]::Exists("WinNT://$env:ComputerName/$LocalGroupName"))
{
Write-Host "$LocalGroupName already exists!" -ForegroundColor "Yellow"
}
else
{
Write-Host "Creating $LocalGroupName local security group" -ForegroundColor "Yellow"
# Create Local User Group
$Computer = [ADSI]"WinNT://$env:ComputerName,Computer"
$LocalGroup = $Computer.Create("group",$LocalGroupName)
$LocalGroup.setinfo()
$LocalGroup.description = $Description
$Localgroup.SetInfo()
Write-Host "$LocalGroupName local security group created" -ForegroundColor "Green"
}
$Group = [ADSI]"WinNT://$env:ComputerName/$LocalGroupName,group"
# Add IIS APPPOOL\DefaultAppPool
$objAccount = New-Object System.Security.Principal.NTAccount("IIS APPPOOL\DefaultAppPool")
$StrSID = $objAccount.Translate([System.Security.Principal.SecurityIdentifier])
$DefaultSID = $StrSID.Value
$Account = [ADSI]"WinNT://$DefaultSID"
$Group.Add($Account.Path)
# Add IIS APPPOOL\Citrix Receiver for Web
$objAccount = New-Object System.Security.Principal.NTAccount("IIS APPPOOL\Citrix Receiver for Web")
$StrSID = $objAccount.Translate([System.Security.Principal.SecurityIdentifier])
$WebRSID = $StrSID.Value
$Account = [ADSI]"WinNT://$WebRSID"
$Group.Add($Account.Path)
<!--NeedCopy-->
Write-Host “AppPools added to $LocalGroupName local group” -ForegroundColor “Green”
SQL Server構成マネージャーを使用して、ローカルSQLインスタンス内で名前付きパイプを有効にします。名前付きパイプは、StoreFrontとSQL Server間のプロセス間通信に必要です。
特定のポートまたは動的ポートを使用してSQL Server接続を許可するように、Windowsファイアウォールルールが正しく構成されていることを確認してください。お使いの環境での設定方法については、Microsoftのドキュメントを参照してください。
> **ヒント:**
>
> ローカルSQLインスタンスへの接続が失敗する場合は、接続文字列で使用されているlocalhostまたは`<hostname>`が正しいIPv4アドレスに解決されていることを確認してください。WindowsはIPv4の代わりにIPv6を使用しようとする場合があり、localhostのDNS解決がStoreFrontおよびSQL Serverの正しいIPv4アドレスではなく::1を返すことがあります。この問題を解決するには、ホストサーバーでIPv6ネットワークスタックを完全に無効にする必要がある場合があります。
### シナリオ 3: StoreFrontサーバーグループと専用のMicrosoft SQL Serverインスタンス
Microsoft SQL Server上に`<SQLServer>\StoreFrontServers`というローカルセキュリティグループを作成し、StoreFrontサーバーグループのすべてのメンバーを追加します。このセキュリティグループは、SQL内にサブスクリプションデータベーススキーマを作成する**Create-StoreSubscriptionsDB-2016.sql**スクリプトで後で参照されます。
すべてのStoreFrontサーバーグループドメインコンピューターアカウントを`<SQLServer>\StoreFrontServers`グループに追加します。SQL ServerでWindows認証が使用されている場合、このグループにリストされているStoreFrontサーバーのドメインコンピューターアカウントのみが、SQL内のサブスクリプションレコードを読み書きできます。スクリプト[Add-RemoteSFAccounts.ps1](https://raw.githubusercontent.com/citrix/sample-scripts/master/storefront/Add-RemoteSFAccounts.ps1)で提供されている以下のPowerShell関数は、ローカルセキュリティグループを作成し、StoreFrontSQL1とStoreFrontSQL2という名前の2つのStoreFrontサーバーを追加します。
<!--NeedCopy-->
```powershell
function Add-RemoteSTFMachineAccounts
{
[CmdletBinding()]
param([Parameter(Mandatory=$True)][string]$Domain,
[Parameter(Mandatory=$True)][array]$StoreFrontServers)
# Create Local Group for StoreFront servers on DB Server
$LocalGroupName = "StoreFrontServers"
$Description = "Contains StoreFront Server Machine Accounts or StoreFront AppPool virtual accounts"
# Check whether the Local Security Group already exists
if ([ADSI]::Exists("WinNT://$env:ComputerName/$LocalGroupName"))
{
Write-Host "$LocalGroupName already exists!" -ForegroundColor "Yellow"
}
else
{
Write-Host "Creating $LocalGroupName local group" -ForegroundColor "Yellow"
# Create Local Security Group
$Computer = [ADSI]"WinNT://$env:ComputerName,Computer"
$LocalGroup = $Computer.Create("group",$LocalGroupName)
$LocalGroup.setinfo()
$LocalGroup.description = $Description
$Localgroup.SetInfo()
Write-Host "$LocalGroupName local group created" -ForegroundColor "Green"
}
Write-Host "Adding $StoreFrontServers to $LocalGroupName local group" -ForegroundColor "Yellow"
foreach ($StoreFrontServer in $StoreFrontServers)
{
$Group = [ADSI]"WinNT://$env:ComputerName/$LocalGroupName,group"
$Computer = [ADSI]"WinNT://$Domain/$StoreFrontServer$"
$Group.Add($Computer.Path)
}
Write-Host "$StoreFrontServers added to $LocalGroupName" -ForegroundColor "Green"
}
Add-RemoteSTFMachineAccounts -Domain "example" -StoreFrontServers @("StoreFrontSQL1","StoreFrontSQL2")
各ストアのMicrosoft SQL Server内でのサブスクリプションデータベーススキーマの構成
StoreFrontで使用するために、Microsoft SQL Server上に名前付きインスタンスを作成します。.SQLスクリプト内のパスを、SQLのバージョンがインストールされている場所、またはそのデータベースファイルが保存されている場所に対応するように設定します。例のスクリプトCreate-StoreSubscriptionsDB-2016.sqlは、SQL Server 2016 Enterpriseを使用しています。
SQL Server Management Studio (SSMS) を使用して、データベースを右クリックし、新しいデータベースを選択して空のデータベースを作成します。
ストアに合わせてデータベース名を入力するか、STFSubscriptionsなどの別の名前を選択します。
スクリプトを実行する前に、StoreFront展開内の各ストアについて、例のスクリプト内の参照をStoreFrontおよびSQL展開に合わせて変更します。たとえば、以下を変更します。
-
作成する各データベースの名前を、
USE [STFSubscriptions]内のStoreFrontのストア名と一致させます。 -
データベースの.mdfファイルと.ldfファイルのパスを、データベースを保存したい場所に設定します。
C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.mdfC:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.ldf -
スクリプト内でSQL Serverの名前への参照を設定します。
CREATE LOGIN [SQL2016\StoreFrontServers] FROM WINDOWS;ALTER LOGIN [SQL2016\StoreFrontServers]
スクリプトを実行します。スキーマの構成が成功すると、SchemaDetails、Subscription、Userの3つのデータベーステーブルが作成されます。
以下のデータベース図は、Create-StoreSubscriptionsDB-2016.sqlスクリプトが作成するサブスクリプションデータベーススキーマを示しています。
各StoreFrontストアのSQL Server接続文字列の構成
シナリオ 1
ヒント:
ESENTデータベースにディスク上に保存されている元のサブスクリプションデータは、破棄または削除されません。Microsoft SQL ServerからESENTの使用に戻すことを決定した場合、ストア接続文字列を削除し、元のデータに切り替えることが可能です。SQLがストアで使用されている間に作成された追加のサブスクリプションはESENTには存在せず、ユーザーはこれらの新しいサブスクリプションレコードを見ることはできません。元のサブスクリプションレコードはすべて引き続き存在します。
ストアでのESENTサブスクリプションの再有効化
PowerShell ISEを開き、管理者として実行を選択します。
ESENTサブスクリプションを再有効化したいストアを指定するには、-UseLocalStorageオプションを使用します。
$SiteID = 1
$StoreVirtualPath = "/Citrix/Store1"
# Sets SQL DB Connection String
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath $StoreVirtualPath
# Removes the SQL DB Connection string and reverts back to using ESENT
Set-STFStoreSubscriptionsDatabase -StoreService $StoreObject -UseLocalStorage
Get-STFStoreSubscriptionsDatabase -StoreService $StoreObject
シナリオ 2、3、および 4
PowerShell ISEを開き、管理者として実行を選択します。
$StoreVirtualPathを使用して、接続文字列を設定したいストアを指定します。
$SiteID = 1
$VirtualPath= "/Citrix/Store1"
$DBName = "Store1"
$DBServer = "SQL2016Ent"
$DBLocalServer = "localhost"
$SQLInstance = "StoreFrontInstance"
# For a remote database instance
$ConnectionString = "Server=$DBServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"
または
# For a locally installed database instance
$ConnectionString = "$DBLocalServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"
# Sets SQL DB Connection String
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath "/Citrix/Store"
Set-STFStoreSubscriptionsDatabase -StoreService $StoreObject -ConnectionString $ConnectionString
Get-STFStoreSubscriptionsDatabase -StoreService $StoreObject
すべてのストアをSQL接続文字列を使用するように構成したい場合は、展開内のすべてのストアに対してこのプロセスを繰り返します。
既存のデータをESENTからMicrosoft SQL Serverへ移行
既存の ESENT データを SQL に移行するには、2 段階のデータ変換プロセスが必要です。この一度限りの操作を実行するために、2 つのスクリプトが提供されています。StoreFront の接続文字列と SQL インスタンスが正しく構成されている場合、すべての新規サブスクリプションは正しい形式で SQL 内に自動的に作成されます。移行後、過去の ESENT サブスクリプションデータは SQL 形式に変換され、ユーザーは以前にサブスクライブしたリソースも確認できるようになります。
例: 同じドメインユーザーに対する 4 つの SQL サブスクリプション
ステップ 1: Transform-SubscriptionDataForStore.ps1 スクリプトを使用した ESENT データの SQL への一括インポートに適した形式への変換
ESENT データを変換する StoreFront サーバーにログオンします。
すべてのサーバーグループメンバーが同じ数のサブスクリプションレコードを含んでいる限り、どのメンバーでも適しています。
PowerShell ISE を開き、[管理者として実行] を選択します。
ESENT データベースから現在のユーザーのデスクトップに <StoreName>.txt ファイルをエクスポートするスクリプト Transform-SubscriptionDataForStore.ps1 を実行します。
PowerShell スクリプトは、処理される各サブスクリプション行について詳細なフィードバックを提供し、デバッグを支援し、操作の成功を評価するのに役立ちます。これには長い時間がかかる場合があります。
スクリプトの完了後、変換されたデータは現在のユーザーのデスクトップに <StoreName>SQL.txt として書き出されます。スクリプトは、一意のユーザーレコードの数と処理されたサブスクリプションの合計数を要約します。
SQL Server に移行するすべてのストアに対して、このプロセスを繰り返します。
ステップ 2: T-SQL ストアドプロシージャを使用した変換済みデータの一括 SQL インポート
各ストアのデータは、一度に 1 つのストアずつインポートする必要があります。
ステップ 1 で作成された <StoreName>SQL.txt ファイルを StoreFront サーバーのデスクトップから Microsoft SQL Server の C:\ にコピーし、SubscriptionsSQL.txt に名前を変更します。
Create-ImportSubscriptionDataSP.sql スクリプトは、サブスクリプションデータを一括インポートするための T-SQL ストアドプロシージャを作成します。これにより、一意のユーザーごとに重複エントリが削除され、結果として得られる SQL データが正しく正規化され、適切なテーブルに分割されます。
Create-ImportSubscriptionDataSP.sql を実行する前に、USE [STFSubscriptions] を、ストアドプロシージャを作成するデータベースと一致するように変更します。
SQL Server Management Studio を使用して Create-ImportSubscriptionDataSP.sql ファイルを開き、その中のコードを実行します。このスクリプトは、以前に作成したデータベースに ImportSubscriptionDataSP ストアドプロシージャを追加します。
ストアドプロシージャが正常に作成されると、SQL コンソールに次のメッセージが表示され、ImportSubscriptionDataSP ストアドプロシージャがデータベースに追加されます。
Commands completed successfully.
ストアドプロシージャを右クリックし、[ストアドプロシージャの実行] を選択し、[OK] をクリックして実行します。
戻り値 0 は、すべてのデータが正常にインポートされたことを示します。インポートに関する問題はすべて SQL コンソールに記録されます。ストアドプロシージャが正常に実行された後、Transform-SubscriptionDataForStore.ps1 が提供するサブスクリプションレコードの合計数と一意のユーザー数を、以下の 2 つの SQL クエリの結果と比較します。2 つの合計は一致するはずです。
変換スクリプトからのサブスクリプションの合計数は、SQL から報告される次の合計数と一致する必要があります。
SELECT COUNT(*) AS TotalSubscriptions
FROM [Subscription]
変換スクリプトからの一意のユーザー数は、SQL から報告される User テーブルのレコード数と一致する必要があります。
SELECT COUNT(*) AS TotalUsers
FROM [User]
変換スクリプトが 100 人の一意のユーザーと 1000 件のサブスクリプションレコードの合計を示している場合、SQL も正常な移行後に同じ 2 つの数値を示すはずです。
StoreFront にログオンして、既存のユーザーがサブスクリプションデータを確認できるかどうかをチェックします。既存のサブスクリプションレコードは、ユーザーがリソースをサブスクライブまたはサブスクライブ解除すると SQL で更新されます。新規ユーザーとサブスクリプションレコードも SQL で作成されます。
ステップ 3: インポートされたデータに対する T-SQL クエリの実行
注:
すべての Delivery Controller 名は大文字と小文字を区別し、StoreFront 内で使用されている大文字と小文字および名前に正確に一致する必要があります。
-- Get all SQL subscription records
Use [STFSubscriptions]
SELECT * FROM [Subscription]
SELECT * FROM [User]
-- Get all subscription records for a particular user SID
Use [STFSubscriptions]
SELECT * FROM [Subscription]
INNER JOIN [User]
ON [Subscription].[user_id] = [User].[id]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'
-- Get total number of Subscription records for a particular user SID
Use [STFSubscriptions]
SELECT COUNT(Subscription.id)
FROM [Subscription]
INNER JOIN [User]
ON [Subscription].[user_id] = [User].[id]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'
-- Get all subscription records for a particular delivery controller
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'
-- OR for aggregated resources use the name of the aggregation group
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'
-- Get all subscription records for a particular application
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] = ' DeliveryController.Application'
T-SQL を使用した既存のサブスクリプションレコードの更新または削除
免責事項:
すべての SQL 更新および削除ステートメントの例は、お客様自身の責任において使用してください。Citrix は、提供された例の誤った使用によるサブスクリプションデータの損失または偶発的な変更について責任を負いません。以下の T-SQL ステートメントは、簡単な更新を実行するためのガイドとして提供されています。サブスクリプションを更新したり、古いレコードを削除したりする前に、SQL データベースの完全バックアップですべてのサブスクリプションデータをバックアップしてください。必要なバックアップを実行しないと、データ損失または破損が発生する可能性があります。本番データベースに対して独自の T-SQL UPDATE または DELETE ステートメントを実行する前に、ダミーデータまたはライブ本番データベースから離れた本番データの冗長コピーでテストしてください。
注:
すべての Delivery Controller 名は大文字と小文字を区別し、StoreFront 内で使用されている大文字と小文字および名前に正確に一致する必要があります。
-- Update the delivery controller used in all subscriptions.
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','NewDeliveryController.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'
-- After enabling multi-site aggregation, update the resource_id
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','DefaultAggregationGroup.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'
-- Delete all subscription records for a particular Delivery Controller
Use [STFSubscriptions]
DELETE FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'
-- OR for aggregated resources use the name of the aggregation group
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'
-- Delete all subscription records for a particular application
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE '%.Application'
-- Delete all subscription records for an application published via a specific delivery controller
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] = 'DeliveryController.Application'
-- Delete all subscription records for a particular user SID
-- relies on cascade to delete records from [Subscription]
Use [STFSubscriptions]
DELETE FROM [User]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'
-- Delete ALL subscription data from a particular database and reset the primary key clustered index to start numbering from 0.
-- USE WITH EXTREME CARE AND NOT ON LIVE PRODUCTION DATABASES.
-- Can be useful whilst debugging data import issues to start with a clean database.
Use [STFSubscriptions]
DELETE FROM [Subscription]
DBCC CHECKIDENT ([Subscription], RESEED, 0)
DELETE FROM [User]
DBCC CHECKIDENT ([User], RESEED, 0)
```