Discussion :

[tck-lt]

Bonjour,

après plusieurs années passées sur un poste de DBA Oracle (+exploitation+Linux) où je me suis "auto-formé" pour l'administration des BDD (pas de tuning ou autres éléments plus complexes pour ne pas être en porte-à-faux par rapport aux éditeurs), me voilà sur un poste plus orienté MS avec en particulier la mise en place de SharePoint 2013 hébergé sous SQL Server 2012. Je découvre donc pas mal de choses et je tente de ré-utiliser des scripts utilisés par mon prédécesseur sur SQL Server 2005.

Mon problème concerne le shrink de mes fichiers de log. Je lance depuis un script PowerShell le plan de maintenance créé sous Studio. Ce plan de maintenance fait une sauvegarde full de mes BDD + sauvegarde des journaux de transaction (=logfiles). Un 2nd script est ensuite lancé pour faire un shrink de ces logfiles et là le bât blesse, je rencontre l'erreur suivante :

Le contexte de la base de données a changé*; il est maintenant 'WSS_Content_SI'.
Impossible de compacter le fichier journal 2 (WSS_Content_SI_log), car le fichier journal logique situé à la fin du fichier est utilisé.
DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages
------ ----------- ----------- ----------- ----------- --------------
24 2 7328 130 7328 128

(1 lignes affectées)
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système.

J'utilise le sql suivant :

USE [WSS_Content_SI]
GO
DBCC SHRINKFILE('WSS_Content_SI_log', 0, TRUNCATEONLY)
GO

appelé par la commande :

sqlcmd -S 127.0.0.1\SHAREPOINT -i "C:\exploite\scripts\Shrink_Log_Bases_Sharepoint\SHRINK_SQL_FILES\WSS_Content_SI_log.sql" -o "C:\exploite\logs\Shrink_Log_Bases_Sharepoint\WSS_Content_SI_log.log"

Quand je passe via Studio pour le faire (clic-droit -> Tâches -> Réduire -> Fichiers puis sélection des journaux de transaction et action "Libérer l'espace inutilisé"), je ne rencontre aucun souci. Avez-vous une explication à me fournir svp ?

2nde question : Est-ce-que ma manière de faire est cohérente svp ?

Merci.

NB : j'irai en formation SQL Server 2012 dans l'année

[Boubou2020]

Bonjour

pourquoi vous faite un shrink log ?

Que te donne ces deux requêtes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC sqlperf(logspace)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SELECT name, recovery_model_desc
   FROM sys.databases
GO

[tck-lt]

Nous faisons des shrinks car certaines de ces bases (en particulier les bases WSS_) finissent par être énormes et générées un max de logs. Elles sont utilisées par SharePoint (GED), il y a donc un nombre de requêtes très important sur ces bases. On vient d'installer SharePoint 2013 et nous allons commencer la migration depuis le 2007. Sur 2007, ces logs nous ont régulièrement posé problème.

Database Name Log Size (MB) Log Space Used (%) Status
-------------------------------------------------------------------------------------------------------------------------------- ------------- ------------------ -----------
master 1,742188 38,00449 0
tempdb 6,117188 37,67561 0
model 0,9921875 54,52756 0
msdb 19,61719 12,87585 0
SP_Config 424,7422 4,119687 0
SP_AdminContent 19,92969 19,04155 0
SP_Content_Ruche2_1 8,304688 21,59572 0
SP_Content_MySites_1 11,17969 18,18221 0
SP_StateService 1,007813 44,0407 0
SP_Metadata 1,304688 35,40419 0
SP_UserProfile 38,99219 12,65528 0
SP_UserProfile_Sync 57,24219 7,48857 0
SP_UserProfile_Social 1,007813 50,04845 0
SP_UsageAndHealth 11,17969 18,56219 0
SP_Search 101,5547 7,150069 0
SP_Search_CrawlStore 57,24219 7,719735 0
SP_Search_AnalyticsReportingStore 1,007813 42,63566 0
SP_Search_LinksStore 101,5547 5,316274 0
SP_Content_Metiers2_1 5,117188 26,93702 0
SP_Content_Projets2_1 6,242188 22,63767 0
SP_Content_GedApplis2_1 6,242188 23,62328 0
WSS_Content_SITEST 79,99219 33,88881 0
WSS_Content_SI1 513,9922 99,40189 0
WSS_Content_SI 57,24219 33,97281 0
WSS_Content_DSI 4,179688 30,1285 0

(25*ligne(s) affectée(s))

Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système.

name recovery_model_desc
-------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------
master SIMPLE
tempdb SIMPLE
model FULL
msdb SIMPLE
SP_Config SIMPLE
SP_AdminContent SIMPLE
SP_Content_Ruche2_1 SIMPLE
SP_Content_MySites_1 SIMPLE
SP_StateService SIMPLE
SP_Metadata SIMPLE
SP_UserProfile SIMPLE
SP_UserProfile_Sync SIMPLE
SP_UserProfile_Social SIMPLE
SP_UsageAndHealth SIMPLE
SP_Search SIMPLE
SP_Search_CrawlStore SIMPLE
SP_Search_AnalyticsReportingStore SIMPLE
SP_Search_LinksStore SIMPLE
SP_Content_Metiers2_1 FULL
SP_Content_Projets2_1 FULL
SP_Content_GedApplis2_1 FULL
WSS_Content_SITEST FULL
WSS_Content_SI1 FULL
WSS_Content_SI FULL
WSS_Content_DSI FULL

J'ai lu des choses sur le shrink de logs et le mode de récupération de la BDD. Je n'ai pas compris quel est le lien entre les 2. Merci de m'éclairer svp.

[Boubou2020]

Utilisez la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC OPENTRAN

pour voir quelle transaction est en cours.

[tck-lt]

Bonjour,

cela a fonctionné pour une partie des bases, les autres ont l'erreur indiquée.

Je viens de refaire le test sur une base voici le script SQL et le résultat associé :

Script :
USE [WSS_Content_SI]
GO
DBCC OPENTRAN
GO
DBCC SHRINKFILE('WSS_Content_SI_log', 0, TRUNCATEONLY)
GO


Résultat :
Le contexte de la base de données a changé*; il est maintenant 'WSS_Content_SI'.
Aucune transaction ouverte active.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système.
Impossible de compacter le fichier journal 2 (WSS_Content_SI_log), car le fichier journal logique situé à la fin du fichier est utilisé.
DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages
------ ----------- ----------- ----------- ----------- --------------
24 2 7328 130 7328 128

(1 lignes affectées)
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système.

[Boubou2020]

votre base était mis en réplication

Que Te donne cette requête ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select name, database_id,recovery_model_desc,log_reuse_wait_desc from sys.databases

il se peut que votre journal n’a pas été tronqué car des enregistrements dans le journal sont en attente de réplication