Almacenar datos de suscripción con Microsoft SQL Server
Nota:
Este documento asume conocimientos básicos de MS SQL Server y consultas T-SQL. Los administradores deben sentirse cómodos configurando, usando y administrando SQL Server antes de intentar seguir este documento.
Introducción
ESENT es un motor de base de datos transaccional incrustable que Windows puede usar. Todas las versiones de StoreFront admiten el uso de una base de datos ESENT integrada de forma predeterminada. También pueden conectarse a una instancia de Microsoft SQL Server si la tienda está configurada para usar una cadena de conexión SQL.
La principal ventaja de cambiar StoreFront para usar SQL en lugar de ESENT es que puedes usar fácilmente sentencias de actualización de SQL para administrar, modificar o eliminar registros de suscripción. Si usas SQL, no necesitas exportar, modificar y volver a importar todos los datos de suscripción de ESENT cada vez que se realicen cambios menores en los datos de suscripción.
Para migrar los datos de suscripción existentes de ESENT a Microsoft SQL Server, los datos planos de ESENT exportados de StoreFront deben transformarse a un formato compatible con SQL para la importación masiva. Para nuevas implementaciones sin datos de suscripción nuevos, este paso no es necesario. El paso de transformación de datos solo se necesita una vez.
Nota:
Los fallos de conexión a la instancia de SQL Server utilizada por StoreFront para almacenar los datos de suscripción debido a interrupciones de red no hacen que la implementación de StoreFront sea inutilizable. Las interrupciones solo resultan en una experiencia de usuario temporalmente degradada; los usuarios no pueden agregar, quitar o ver recursos favoritos hasta que se restablezca la conexión a SQL Server. Los recursos aún se pueden enumerar e iniciar durante la interrupción. El comportamiento esperado es el mismo que si el servicio Citrix Subscription Store se detuviera mientras se usa ESENT.
Sugerencia:
Los recursos configurados con KEYWORDS:Auto o KEYWORDS:Mandatory se comportan de la misma manera al usar ESENT o SQL. Los nuevos registros de suscripción de SQL se crean automáticamente cuando un usuario inicia sesión por primera vez si alguna de estas PALABRAS CLAVE se incluye en los recursos del usuario.
Ventajas de ESENT y SQL Server
| ESENT | SQL |
|---|---|
| Predeterminado y no requiere configuración adicional para usar StoreFront “listo para usar”. | Mucho más manejable y los datos de suscripción se pueden manipular o actualizar fácilmente con consultas T-SQL. Permite eliminar o actualizar registros por usuario. Permite contar fácilmente los registros por aplicación, controlador de entrega o usuario. Permite quitar fácilmente los datos de usuario innecesarios para los usuarios que han dejado la empresa u organización. Permite actualizar fácilmente las referencias del controlador de entrega, como cuando el administrador cambia a usar la agregación o se aprovisionan nuevos controladores de entrega. |
| Más sencillo de configurar la replicación entre diferentes grupos de servidores usando la sincronización de suscripciones y los programas de extracción. Consulta Configurar la sincronización de suscripciones | Desacoplado de StoreFront, por lo que no es necesario hacer una copia de seguridad de los datos de suscripción antes de la actualización de StoreFront, ya que los datos se mantienen en un servidor SQL independiente. La copia de seguridad de suscripciones es independiente de StoreFront y usa estrategias y mecanismos de copia de seguridad de SQL. |
| SQL innecesario cuando no se necesita la gestión de suscripciones. Si los datos de suscripción nunca necesitarán actualizarse, es probable que ESENT satisfaga las necesidades del cliente. | Una sola copia de los datos de suscripción compartida por todos los miembros del grupo de servidores, por lo que hay menos posibilidades de diferencias de datos entre servidores o problemas de sincronización de datos. |
Desventajas de ESENT y SQL Server
| ESENT | SQL |
|---|---|
| No hay medios fáciles para administrar los datos de suscripción de manera sencilla y granular. Requiere que las manipulaciones de suscripciones se realicen en archivos .txt exportados. Toda la base de datos de suscripciones debe exportarse y volver a importarse. Potencialmente, miles de registros pueden necesitar ser cambiados usando técnicas de buscar y reemplazar, lo cual es laborioso y potencialmente propenso a errores. | Requiere experiencia básica en SQL e infraestructura. Puede requerir la compra de una licencia de SQL, lo que aumenta el costo total de propiedad de la implementación de StoreFront. Aunque una instancia de base de datos de Citrix Virtual Apps and Desktops también se puede compartir con StoreFront para reducir los costos. |
| Se debe mantener una copia de la base de datos ESENT en cada servidor StoreFront dentro de un grupo de servidores. En raras ocasiones, esta base de datos puede desincronizarse dentro de un grupo de servidores o entre diferentes grupos de servidores. | La replicación de datos de suscripción entre grupos de servidores es una tarea de implementación no trivial. Requiere múltiples instancias de SQL y replicación de transacciones entre cada una de ellas por centro de datos. Esto requiere experiencia especializada en MS SQL. |
| Se requiere la migración de datos de ESENT y la transformación a un formato compatible con SQL. Este proceso solo se requiere una vez. | |
| Es posible que se necesiten servidores y licencias de Windows adicionales. | |
| Pasos adicionales para implementar StoreFront. |
Escenarios de implementación
Nota:
Cada tienda configurada en StoreFront requiere una base de datos ESENT o una base de datos de Microsoft SQL si quieres admitir suscripciones de usuario. El método de almacenamiento de los datos de suscripción se establece a nivel de tienda dentro de StoreFront.
Citrix® recomienda que todas las bases de datos de la tienda residan en la misma instancia de Microsoft SQL Server para reducir la complejidad de la gestión y el alcance de la configuración incorrecta.
Varias tiendas pueden compartir la misma base de datos, siempre que todas estén configuradas para usar la misma cadena de conexión idéntica. No importa si usan diferentes controladores de entrega. La desventaja de que varias tiendas compartan una base de datos es que no hay forma de saber a qué tienda corresponde cada registro de suscripción.
Una combinación de los dos métodos de almacenamiento de datos es técnicamente posible en una única implementación de StoreFront con varias tiendas. Es posible configurar una tienda para usar ESENT y otra para usar SQL. Esto no se recomienda debido al aumento de la complejidad de la gestión y al alcance de la configuración incorrecta.
Hay cuatro escenarios que puedes usar para almacenar datos de suscripción en SQL Server:
Escenario 1: Servidor StoreFront único o grupo de servidores que usa ESENT (predeterminado)
De forma predeterminada, todas las versiones de StoreFront desde la versión 2.0 usan una base de datos ESENT plana para almacenar y replicar datos de suscripción entre los miembros de un grupo de servidores. Cada miembro del grupo de servidores mantiene una copia idéntica de la base de datos de suscripciones, que se sincroniza con todos los demás miembros del grupo de servidores. Este escenario no requiere pasos adicionales para configurarse. Este escenario es adecuado para la mayoría de los clientes que no esperan cambios frecuentes en los nombres de los controladores de entrega o que no necesitan realizar tareas de gestión frecuentes en sus datos de suscripción, como quitar o actualizar suscripciones de usuario antiguas.
Escenario 2: Servidor StoreFront único y una instancia local de Microsoft SQL Server instalada
StoreFront usa una instancia de SQL Server instalada localmente y ambos componentes residen en el mismo servidor. Este escenario es adecuado para una implementación sencilla de StoreFront único donde los clientes podrían necesitar realizar cambios frecuentes en los nombres de los controladores de entrega, o necesitan realizar tareas de gestión frecuentes en sus datos de suscripción, como quitar o actualizar suscripciones de usuario antiguas, pero no requieren una implementación de StoreFront de alta disponibilidad. Citrix no recomienda este escenario para grupos de servidores porque crea un único punto de fallo en el miembro del grupo de servidores que aloja la instancia de base de datos de Microsoft SQL. Este escenario no es adecuado para grandes implementaciones empresariales.
Escenario 3: Grupo de servidores StoreFront y una instancia dedicada de Microsoft SQL Server configurada para alta disponibilidad (recomendado)
Todos los miembros del grupo de servidores StoreFront se conectan a la misma instancia dedicada de Microsoft SQL Server o a un clúster de conmutación por error de SQL. Este es el modelo más adecuado para grandes implementaciones empresariales donde los administradores de Citrix quieren realizar cambios frecuentes en los nombres de los controladores de entrega o quieren realizar tareas de gestión frecuentes en sus datos de suscripción, como quitar o actualizar suscripciones de usuario antiguas, y requieren alta disponibilidad.
Escenario 4: Múltiples grupos de servidores StoreFront y una instancia dedicada de Microsoft SQL Server en cada centro de datos por grupo de servidores
Nota:
Esta es una configuración avanzada. Solo inténtala si eres un administrador de SQL Server experimentado y familiarizado con la replicación transaccional, y tienes las habilidades necesarias para implementarla con éxito.
Esto es lo mismo que el escenario 3, pero lo extiende a situaciones en las que se requieren múltiples grupos de servidores StoreFront en diferentes centros de datos remotos. Los administradores de Citrix pueden optar por sincronizar los datos de suscripción entre diferentes grupos de servidores en los mismos o diferentes centros de datos. Cada grupo de servidores en el centro de datos se conecta a su propia instancia dedicada de Microsoft SQL Server para redundancia, conmutación por error y rendimiento. Este escenario requiere una configuración e infraestructura de Microsoft SQL Server considerablemente adicionales. Se basa completamente en la tecnología de Microsoft SQL para replicar los datos de suscripción y sus transacciones SQL.
Recursos
Puedes descargar los siguientes scripts desde https://github.com/citrix/sample-scripts/tree/master/storefront para ayudarte:
Scripts de configuración
-
Set-STFDatabase.ps1 – establece la cadena de conexión de MS SQL para cada tienda. Ejecútalo en el servidor StoreFront.
-
Add-LocalAppPoolAccounts.ps1 – otorga a los grupos de aplicaciones del servidor StoreFront local acceso de lectura y escritura a la base de datos SQL. Ejecútalo para el escenario 2 en el servidor SQL.
-
Add-RemoteSFAccounts.ps1 – otorga a todos los servidores StoreFront de un grupo de servidores acceso de lectura y escritura a la base de datos SQL. Ejecútalo para el escenario 3 en el servidor SQL.
-
Create-StoreSubscriptionsDB-2016.sql – crea la base de datos y el esquema SQL. Ejecútalo en el servidor SQL.
Scripts de transformación e importación de datos
-
Transform-SubscriptionDataForStore.ps1 – exporta y transforma los datos de suscripción existentes dentro de ESENT a un formato compatible con SQL para la importación.
-
Create-ImportSubscriptionDataSP.sql – crea un procedimiento almacenado para importar los datos transformados por Transform-SubscriptionDataForStore.ps1. Ejecuta este script una vez en el servidor SQL después de haber creado el esquema de la base de datos usando Create-StoreSubscriptionsDB-2016.sql.
Configurar el grupo de seguridad local del servidor StoreFront en SQL Server
Escenario 2: Servidor StoreFront único y una instancia local de Microsoft SQL Server instalada
Crea un grupo de seguridad local llamado <SQLServer>\StoreFrontServers en el servidor de Microsoft SQL, y agrega las cuentas virtuales para IIS APPPOOL\DefaultAppPool y IIS APPPOOL\Citrix Receiver for Web para permitir que el StoreFront instalado localmente lea y escriba en SQL. Este grupo de seguridad se referencia en el script .SQL que crea el esquema de la base de datos de suscripciones de la tienda, así que asegúrate de que el nombre del grupo coincida.
Puedes descargar el script Add-LocalAppPoolAccounts.ps1 para ayudarte.
Instala StoreFront antes de ejecutar el script Add-LocalAppPoolAccounts.ps1. El script depende de la capacidad de localizar la cuenta virtual de IIS IIS APPPOOL\Citrix Receiver for Web, que no existe hasta que StoreFront se ha instalado y configurado. IIS APPPOOL\DefaultAppPool se crea automáticamente al instalar el rol de servidor web de IIS.
# 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”
Habilita las canalizaciones con nombre en tu instancia local de SQL mediante el administrador de configuración de SQL Server. Las canalizaciones con nombre son necesarias para la comunicación entre procesos entre StoreFront y SQL Server.
Asegúrate de que las reglas del firewall de Windows estén configuradas correctamente para permitir las conexiones de SQL Server mediante un puerto específico o puertos dinámicos. Consulta la documentación de Microsoft para saber cómo hacerlo en tu entorno.
> **Consejo:**
>
> Si la conexión a la instancia local de SQL falla, comprueba que `localhost` o `<hostname>` usados en la cadena de conexión se resuelvan a la dirección IPv4 correcta. Windows puede intentar usar IPv6 en lugar de IPv4, y la resolución DNS de `localhost` puede devolver `::1` en lugar de la dirección IPv4 correcta de StoreFront y SQL Server. Es posible que sea necesario deshabilitar completamente la pila de red IPv6 en el servidor host para resolver este problema.
### Escenario 3: Grupo de servidores de StoreFront y una instancia dedicada de Microsoft SQL Server
Crea un grupo de seguridad local llamado `<SQLServer>\StoreFrontServers` en el servidor Microsoft SQL y agrega a todos los miembros del grupo de servidores de StoreFront. Este grupo de seguridad se menciona más adelante en el script **Create-StoreSubscriptionsDB-2016.sql** que crea el esquema de la base de datos de suscripciones en SQL.
Agrega todas las cuentas de equipo de dominio del grupo de servidores de StoreFront al grupo `<SQLServer>\StoreFrontServers`. Solo las cuentas de equipo de dominio del servidor de StoreFront que figuran en el grupo podrán leer y escribir registros de suscripciones en SQL si SQL Server usa la autenticación de Windows. La siguiente función de PowerShell, proporcionada en el script [Add-RemoteSFAccounts.ps1](https://raw.githubusercontent.com/citrix/sample-scripts/master/storefront/Add-RemoteSFAccounts.ps1), crea el grupo de seguridad local y le agrega dos servidores de StoreFront llamados StoreFrontSQL1 y StoreFrontSQL2.
<!--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")
Configura el esquema de la base de datos de suscripciones en Microsoft SQL Server para cada almacén
Crea una instancia con nombre en tu servidor Microsoft SQL para que la use StoreFront. Establece la ruta dentro del script .SQL para que se corresponda con la ubicación donde está instalada tu versión de SQL o donde se almacenan sus archivos de base de datos. El script de ejemplo Create-StoreSubscriptionsDB-2016.sql usa SQL Server 2016 Enterprise.
Crea una base de datos vacía mediante SQL Server Management Studio (SSMS) haciendo clic con el botón derecho en Bases de datos y, a continuación, seleccionando Nueva base de datos.
Escribe un Nombre de base de datos para que coincida con tu almacén o elige un nombre diferente, como STFSubscriptions.
Antes de ejecutar el script, para cada almacén de tu implementación de StoreFront, modifica las referencias en el script de ejemplo para que coincidan con tus implementaciones de StoreFront y SQL. Por ejemplo, modifica:
-
Asigna un nombre a cada base de datos que crees para que coincida con el nombre del almacén en StoreFront en
USE [STFSubscriptions]. -
Establece la ruta a los archivos .mdf y .ldf de la base de datos donde quieras almacenar la base de datos.
C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.mdfC:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.ldf -
Establece la referencia al nombre de tu servidor SQL dentro del script:
CREATE LOGIN [SQL2016\StoreFrontServers] FROM WINDOWS;ALTER LOGIN [SQL2016\StoreFrontServers]
Ejecuta el script. Después de configurar correctamente el esquema, se crean tres tablas de base de datos: SchemaDetails, Subscription y User.
El siguiente diagrama de base de datos muestra el esquema de la base de datos de suscripciones que crea el script Create-StoreSubscriptionsDB-2016.sql:
Configura la cadena de conexión de SQL Server para cada almacén de StoreFront
Escenario 1
Consejo:
Los datos de suscripción originales almacenados en el disco en la base de datos ESENT no se destruyen ni se eliminan. Si decides revertir de Microsoft SQL Server a usar ESENT, es posible quitar la cadena de conexión del almacén y simplemente volver a usar los datos originales. Cualquier suscripción adicional que se haya creado mientras SQL estaba en uso para el almacén no existirá en ESENT y los usuarios no verán estos nuevos registros de suscripción. Todos los registros de suscripciones originales seguirán estando presentes.
Para volver a habilitar las suscripciones de ESENT en un almacén
Abre PowerShell ISE y selecciona Ejecutar como administrador.
Usa la opción -UseLocalStorage para especificar el almacén en el que quieres volver a habilitar las suscripciones de ESENT:
$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
Escenarios 2, 3 y 4
Abre PowerShell ISE y selecciona Ejecutar como administrador.
Especifica el almacén para el que quieres establecer una cadena de conexión mediante $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;"
O
# 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
Repite el proceso para cada almacén de tu implementación si quieres configurarlos todos para que usen una cadena de conexión SQL.
Migra los datos existentes de ESENT a Microsoft SQL Server
Para migrar tus datos ESENT existentes a SQL, se requiere un proceso de transformación de datos de dos pasos. Se proporcionan dos scripts para ayudarte a realizar esta operación única. Si la cadena de conexión en StoreFront y la instancia de SQL están configuradas correctamente, todas las nuevas suscripciones se crearán automáticamente en SQL con el formato correcto. Después de la migración, los datos históricos de suscripción de ESENT se transforman a un formato SQL y los usuarios también pueden ver sus recursos previamente suscritos.
Ejemplo: cuatro suscripciones SQL para el mismo usuario de dominio
Paso 1: Usa el script Transform-SubscriptionDataForStore.ps1 para convertir los datos ESENT a un formato compatible con SQL para importación masiva
Inicia sesión en el servidor de StoreFront desde el que quieres transformar los datos ESENT.
Cualquier miembro de un grupo de servidores es adecuado, siempre que todos contengan el mismo número de registros de suscripción.
Abre PowerShell ISE y selecciona Ejecutar como administrador.
Ejecuta el script Transform-SubscriptionDataForStore.ps1 que exporta un archivo <StoreName>.txt desde la base de datos ESENT al escritorio del usuario actual.
El script de PowerShell proporciona información detallada sobre cada fila de suscripción procesada para facilitar la depuración y ayudarte a evaluar el éxito de la operación. Esto puede tardar mucho tiempo en procesarse.
Los datos transformados se escriben en <StoreName>SQL.txt en el escritorio del usuario actual una vez que el script ha finalizado. El script resume el número de registros de usuario únicos y el número total de suscripciones procesadas.
Repite este proceso para cada almacén que quieras migrar al servidor SQL.
Paso 2: Usa un procedimiento almacenado de T-SQL para importar masivamente los datos transformados a SQL
Los datos de cada almacén deben importarse de uno en uno.
Copia el archivo <StoreName>SQL.txt creado en el Paso 1 desde el escritorio del servidor de StoreFront a C:\ en el servidor de Microsoft SQL y renómbralo a SubscriptionsSQL.txt.
El script Create-ImportSubscriptionDataSP.sql crea un procedimiento almacenado de T-SQL para importar masivamente los datos de suscripción. Elimina las entradas duplicadas para cada usuario único, de modo que los datos SQL resultantes se normalizan correctamente y se dividen en las tablas adecuadas.
Antes de ejecutar Create-ImportSubscriptionDataSP.sql, cambia USE [STFSubscriptions] para que coincida con la base de datos en la que quieres crear el procedimiento almacenado.
Abre el archivo Create-ImportSubscriptionDataSP.sql usando SQL Server Management Studio y ejecuta el código que contiene. Este script agrega el procedimiento almacenado ImportSubscriptionDataSP a la base de datos que creaste anteriormente.
Después de la creación exitosa del procedimiento almacenado, se muestra el siguiente mensaje en la consola SQL, y el procedimiento almacenado ImportSubscriptionDataSP se agrega a la base de datos:
Commands completed successfully.
Ejecuta el procedimiento almacenado haciendo clic derecho sobre él, luego selecciona Ejecutar procedimiento almacenado y haz clic en Aceptar.
Un valor de retorno de 0 indica que todos los datos se importaron correctamente. Cualquier problema durante la importación se registra en la consola SQL. Después de que el procedimiento almacenado se haya ejecutado con éxito, compara el número total de registros de suscripción y usuarios únicos que proporciona Transform-SubscriptionDataForStore.ps1 con el resultado de las dos consultas SQL siguientes. Los dos totales deben coincidir.
El número total de suscripciones del script de transformación debe coincidir con el número total reportado desde SQL mediante
SELECT COUNT(*) AS TotalSubscriptions
FROM [Subscription]
El número de usos únicos del script de transformación debe coincidir con el número de registros en la tabla User reportado desde SQL mediante
SELECT COUNT(*) AS TotalUsers
FROM [User]
Si el script de transformación muestra 100 usuarios únicos y 1000 registros de suscripción totales, entonces SQL debería mostrar los mismos dos números después de una migración exitosa.
Inicia sesión en StoreFront para verificar si los usuarios existentes pueden ver sus datos de suscripción. Los registros de suscripción existentes se actualizan en SQL cuando los usuarios se suscriben o cancelan la suscripción a sus recursos. También se crean nuevos usuarios y registros de suscripción en SQL.
Paso 3: Ejecuta consultas T-SQL en tus datos importados
Nota:
Todos los nombres de Delivery Controller distinguen entre mayúsculas y minúsculas y deben coincidir exactamente con el uso de mayúsculas y minúsculas y el nombre utilizado en 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'
Actualizar o eliminar registros de suscripción existentes usando T-SQL
AVISO LEGAL:
Todas las sentencias de ejemplo de actualización y eliminación de SQL se utilizan bajo tu propio riesgo. Citrix no se hace responsable de ninguna pérdida o alteración accidental de tus datos de suscripción por el uso incorrecto de los ejemplos proporcionados. Las siguientes sentencias T-SQL se proporcionan como guía para permitir la realización de actualizaciones sencillas. Realiza una copia de seguridad completa de todos los datos de suscripción en la base de datos SQL antes de intentar actualizar tus suscripciones o eliminar registros obsoletos. No realizar las copias de seguridad necesarias puede resultar en pérdida o corrupción de datos. Antes de ejecutar tus propias sentencias T-SQL UPDATE o DELETE contra la base de datos de producción, pruébalas con datos ficticios o en una copia redundante de los datos de producción, lejos de la base de datos de producción en vivo.
Nota:
Todos los nombres de sitio distinguen entre mayúsculas y minúsculas y deben coincidir exactamente con el uso de mayúsculas y minúsculas y el nombre utilizado en StoreFront.
-- Update the site name used in all subscriptions.
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldSiteName.','NewSiteName.')
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 site
Use [STFSubscriptions]
DELETE FROM [Subscription]
WHERE [resource_id] LIKE 'site.%'
-- 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 site
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] = 'Site.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)
```
En este artículo
- Introducción
- Configurar el grupo de seguridad local del servidor StoreFront en SQL Server
- Configura el esquema de la base de datos de suscripciones en Microsoft SQL Server para cada almacén
- Configura la cadena de conexión de SQL Server para cada almacén de StoreFront
- Migra los datos existentes de ESENT a Microsoft SQL Server
- Actualizar o eliminar registros de suscripción existentes usando T-SQL