Contexte
Lors de la suppression d’un des fichiers utilisé par la base TempDB, l’opération échoue avec l’erreur suivante :
Msg 5042, Level 16, State 1, Line 1
The file 'tempdev2' cannot be removed because it is not empty.
Explication
Ce comportement est provoqué par le fait que le fichier est actuellement utilisé par SQL, il faut donc vider le fichier avant de pouvoir le supprimer.
Une solution possible est le redemmarage de l’instance SQL, ce qui va regenerer la base TempDB, moyennant une coupure de service.
Résolution
Afin d’éviter toute coupure de service, il est possible d’executer le script SQL suivant pour vider puis supprimer un fichier utilisé par la TempDB :
USE [tempdb]
GO
DBCC SHRINKFILE('tempdev2', EMPTYFILE)
GO
ALTER DATABASE [tempdb] REMOVE FILE [tempdev2]
GO
Sources
https://tenbulls.co.uk/2016/01/13/problem-removing-files-from-tempdb/
Introduction
Après avoir renommé un serveur SQL, les plans de maintenances existants échouent avec l’erreur suivante :
Réalisation
1. Lister les procédures stockées en exécutant le script suivant sur la base MSDB et récupérer la valeur “ID” :
| SELECT x.*,
LocalServerConnectionString = cm.value('declare namespace DTS="www.microsoft.com/SqlServer/Dts";DTS:ObjectData[1]/DTS:ConnectionManager[1]/@DTS:ConnectionString', 'varchar(1000)')
FROM (
SELECT id, name, packageXML = CAST(CAST(packagedata AS VARBINARY(MAX)) AS XML)
FROM dbo.sysssispackages
WHERE id IN (SELECT id FROM dbo.sysmaintplan_plans)
) x
CROSS APPLY packageXML.nodes('declare namespace DTS="www.microsoft.com/SqlServer/Dts";/DTS:Executable/DTS:ConnectionManagers/DTS:ConnectionManager[@DTS:ObjectName="Local server connection"]') p(cm) |
Voici un exemple de résultat :
2. Modifier la valeur “Data Source” à l’aide du script suivant :
| UPDATE dbo.sysssispackages SET packagedata = CAST(CAST(REPLACE(CAST(CAST(packagedata AS VARBINARY(MAX)) AS VARCHAR(MAX)), 'OldServerName', 'NewServerName') AS XML) AS VARBINARY(MAX))
WHERE id = ‘ID' |
Modifier les valeur en rouge :
- OldServerName : Ancien nom de l’instance SQL telle qu’indiquée dans la partie “Data Source” de la colonne “LocalServerConnectionString” de la requête exécutée précédemment,
- NewServerName : Nouveau nom de l’instance SQL,
- ID : GUID de la tâche planifiée à reconfigurée telle qu’indiquée dans la colonne“ID” de la requête exécutée précédemment.
Vérification
- Valider en exécutant la requête listant les procédure stockées que le nom de la nouvelle instance apparaît bien dans la partie “Data Source” de la colonne “LocalServerConnectionString”,
- Exécuter le plan de maintenance et valider qu’il s’exécute correctement.
Liens Utiles
Introduction
Lors de la publication d’une application WEB via KEMP, vous pouvez être amené à publier l’application en utilisant une URL différente de celle utilisée en interne.
Cet article explique la configuration à mettre en place afin de publier une application sous différents noms sans avoir à créer les bindings correspondant sur le serveur WEB.
Contexte
Une application nommée “APPLI1” est utilisée en interne via l’URL “https://appli1.internaldomain.dom”, le domaine publié en externe est nommé “https://appli1.externaldomain.com”.
L’application “APPLI1” ne supportant pas l’utilisation de bindings multiples, le KEMP de publication doit donc
- recevoir depuis l’extérieur les demandes provenant de l’URL “https://appli1.externaldomain.com”
- transmettre ces demandes en interne vers l’URL “https://appli1.internaldomain.dom”
Réalisation
Afin de mettre en place la réécriture d’URL, il faut créer les règles suivantes :
HTTP Header Modifications Rule :
Cette règle seras utilisée pour transformer l’URL “appli1.externaldomain.com” en “appli1.internaldomain.dom”
Cette règle doit être appliquée au niveau de la VIP dans “Advanced Properties\HTTP Header Modification”
Content Matching Rule :
Cette règle est utilisée afin que la VIP réponde à l’URL “*.externaldomain.com/*”
L’option content switching doit être activée depuis “Advanced Properties\Content Switching”
Cette règle doit être appliquée au niveau de la VIP dans “Real Servers\Rules” pour chaque serveur devant répondre à l’URL externe
Dans le cas où l’URL interne serait également publiée, il faut penser à activer la “default” content switching rule niveau de la VIP dans “Real Servers\Rules” pour chaque serveur devant répondre à l’URL externe et interne, la default rule doit toujours être positionnée en dernier :
Lors du déploiement du Rôle RDS sur Windows Server 2012 R2, il se peut que vous rencontriez l'erreur suivante :
"Le serveur est en attente de redémarrage et doit être redémarré."
Cette erreur se présente lorsque si vous avez récemment passé une mise à jour ou installer un rôle ou une fonctionnalité sans redémarrer.
Si même après avoir redémarré cela ne change rien, vérifier si la clé de registre suivante existe :
"HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations"
Si elle existe faites un backup de votre registre, puis supprimez la clé.
Normalement vous pouvez maintenant installer le Rôle RDS sans soucis.