Discussion :

[janlouk]

Bonjour à tous,

J'ai la chance d'arriver dans un endroit où il y a beaucoup de boulot à faire. Je suis tombé sur une instance où les DB appartiennent à SAP, des DB parfois de 50 GB avec autogrowth à 1MB... Et parfois à 10 %

"On" m'a dit par exemple "Les DB Sharepoint, on ne touche pas". Pourtant, aussi bien Sharepoint, SAP, Biztalk, puis-je (dois-je) modifier l'autogrowth et le mettre en MB ?

Pareil, je vois aussi que sur certaines (je ne sais pas encore de quelle application) l'autoCreateStats et autoUpdateStats sont sur off. Ou même, certaines ont l'autoshrink d'activé.

Ma question, en fonction des applications qu'il y a derrière, comment dois-je réagir ? Y a t'il des choses des bonnes pratiques d'SQL Server que je ne dois pas appliquer ?

Merci
Jean-Luc

[SQLpro]

Certains éditeurs gèrent tout ceci par des process préprogrammés. Par exemple pour Sharepoint, ne surtout pas toucher la config du serveur.

Il faut donc voir quels sont les travaux, les analyser et discuter avec les éditeurs.

A +

[Boubou2020]

je ne sais pas comment vous sauvegarder vos site sharepoint

mais je te conseil de mettre la base "SharePoint_Config" en mode récupération simple car La taille du fichier Sharepoint_config_name_log.LDF peut considérablement augmenter dans une base de données SQL

autre chose essayer d'auditer bien vos index sur la base WSS_Search car cette dernier est utiliser pour le moteur du recherche du SharePoint

cordialement

[Bernardos]

Bonjour,

mais je te conseil de mettre la base "SharePoint_Config" en mode récupération simple car La taille du fichier Sharepoint_config_name_log.LDF peut considérablement augmenter dans une base de données SQL

Ce que vous dites me fait penser que vous n'avez pas compris ce qu'est le mode de récupération "complet". en mode complet, votre fichier journal de transaction ne se vide que lorsque vous faites une sauvegarde du journal de transaction.
Ce mode de récupération permet d'établir une stratégie de sauvegarde fine ou par exemple, tu fais un backup full tous les Lundi, un backup diff tous les autres jours, et une sauvegarde du journal de transactions toutes les heures.
Après, je ne suis pas spécialiste sharepoint, donc je ne peux pas juger de la pertinence de choisir un mode ou l'autre.
Cordialement,

[Boubou2020]

bonjour

aucun utilité de sauvegarder cette base

je suppose que tu sauvegarde cette base du façon régulier ,tu ne peux rien faire avec ce backup

c'est pour cela avec l'absence d'une stratégie sauvegarde régulier sur cette base je l'ai conseillé de le mettre en mode simple

même la commande Stsadm dédier pour sauvegarder un site sharepoint n'attaque pas cette base

cordialement

[mikedavem]

"On" m'a dit par exemple "Les DB Sharepoint, on ne touche pas". Pourtant, aussi bien Sharepoint, SAP, Biztalk, puis-je (dois-je) modifier l'autogrowth et le mettre en MB ?

Pareil, je vois aussi que sur certaines (je ne sais pas encore de quelle application) l'autoCreateStats et autoUpdateStats sont sur off. Ou même, certaines ont l'autoshrink d'activé.
Y a t'il des choses des bonnes pratiques d'SQL Server que je ne dois pas appliquer

Il y a des choses que tu peux faire avec SharePoint et d'autres non. Augmenter la taille d'un fichier, gérer les auto extent et autre il n'y aura jamais de souci.
Cependant d'autres choses ne seront pas possibles ou pas "supportés" par les différents éditeurs de logiciels. Il faut malheureusement prendre connaissance de la documentation associée quand celle-ci existe.

Par exemple SharePoint > https://technet.microsoft.com/en-us/.../hh292622.aspx

Pour SAP en général il faut recouper avec les gens de la team concernée afin qu'il te fournisse bonne documentation depuis leur espace client. Pour SAP, la documentations est en générale difficile d'accès si tu n'as pas un compte chez eux (d'après ma propre expérience mais possible que d'autres diront le contraire).

++

[janlouk]

Ok, bon je vais alors essayer d'identifier chaque DB, l'application qui tourne derrière et contacter les équipes qui les ont créé.

Mais je suppose que si je modifiais la DB Model, en choisi les MB et pas des %. Normalement, les applications vont suivre la DB Model ou peuvent utiliser automatiquement une config propre ?

J'ai l'impression, que vu le nombre de clients et d'instances, j'ai du boulot pour plusieurs années

[mikedavem]

Mais je suppose que si je modifiais la DB Model, en choisi les MB et pas des %. Normalement, les applications vont suivre la DB Model ou peuvent utiliser automatiquement une config propre ?

Ils peuvent aussi utiliser des configurations spécifiques :-) En configurant model tu limites la casse disons. Après tu peux toujours passer derrière pour régler le problème.
Cela me faisait penser il y a quelques années, nous avions mis en place PBM avec des règles de standardisation chez un client pour détecter les écarts avec les bases de données au cours du temps.
On corrigeait au fur et à mesure en fonction du cas. Cela évitait d'avoir à faire cela manuellement (aucune valeur ajoutée à mon sens).

J'ai l'impression, que vu le nombre de clients et d'instances, j'ai du boulot pour plusieurs années

Pas une bonne nouvelle pour toi ça ?

++

[cristophe0071983]

Bref, les mots me manque pour dire la stupidité des propos que l'on trouve dans certains sujet

[mikedavem]

Bref, les mots me manquent pour dire la stupidité des propos que l'on trouve dans certains sujets

Lesquels que l'on puisse profiter avec toi

++

[janlouk]

Ils peuvent aussi utiliser des configurations spécifiques :-) En configurant model tu limites la casse disons. Après tu peux toujours passer derrière pour régler le problème.
Cela me faisait penser il y a quelques années, nous avions mis en place PBM avec des règles de standardisation chez un client pour détecter les écarts avec les bases de données au cours du temps.
On corrigeait au fur et à mesure en fonction du cas. Cela évitait d'avoir à faire cela manuellement (aucune valeur ajoutée à mon sens).

Bon, je vais de toute façon mettre aussi en place les policies et voir ce que ça donne. Mais je serai plus prudent, je ne l'aurais pas fait sans accord, mais au moins je sais que je peux quand même insister au moins pour les autogrowth.

Pas une bonne nouvelle pour toi ça ?

Oui c'est sûr, en espérant qu'ils aient le budget pour toute l'année 2017 :-)