[SPS2003][WSS2003]database maintenance

Le
olivier
Bonjour à tous,

J'utilise sps2003 en environnement SQL serveur 2000 (1 serveur pour le
portail, 1 serveur pour la base).

Ma question est la suivante :

Nous avons un programme qui fait des insertions massive dans sharepoint
(5000 à 6000 par nuit) et il semble que depuis quelques jours les
performances se soient completement écroulées (le temps d'insertion a
progressivement été multiplié par 10 depuis le debut)

Y a t-il des procedures de maintenance au niveau de la base SQL qui
permetteraient d'optimiser l'insertion dans la base ?

Il semble que le nombre de document par niveau (dossier) dépasse les
recommendations de microsoft (dans certains dossiers il y a plus de 6000
documents) , mais d'apres ce que j'ai pu comprendre c'est seulement la visue
dans la bibliotheque de document qui sera penalisé, pas l'insertion.
Tous les documents sont insérés dans la même bilbiotheque de documents,
aujourd'hui nous avons environ 65000 documents répartis sur plusieurs
niveau.


Merci d'avance de vos commentaires avisés.

Olivier
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
TG2K
Le #16978301
Bonjour,

On 14 déc, 10:19, "olivier"
Nous avons un programme qui fait des insertions massive dans sharepoint
(5000 à 6000 par nuit) et il semble que depuis quelques jours les
performances se soient completement écroulées (le temps d'insertion a
progressivement été multiplié par 10 depuis le debut)



Sans maintenance SQL, en effet, c'est possible et même probable. Y a-t-
il suppression puis insertion, ou simple insertion ?

Y a t-il des procedures de maintenance au niveau de la base SQL qui
permetteraient d'optimiser l'insertion dans la base ?



Regardez la taille de vos fichiers de base de données:
- les MDF (data)
- les LDF (transaction logs)
Je parie pour ces derniers que leur taille vous intriguera si
effectivement vous réalisez des opérations "en masse" de cette
envergure.

Agir "en masse" comme vous le faîtes me pousse à vous recommander
l'usage (dans SQL) du mode de recovery "Bulk logged" pour les bases
concernées (Options). Si vous n'êtes pas très au fait de ces
possibilités, je vous invite à vous renseigner tout de même avant
d'agir (mot clé bulk logged sur Google, et un bon dba -ce qui n'est
pas mon cas- devraient faire l'affaire).
Réfléchir avant à votre méthode de backup et restore, perte de donn ées
maximale admissible, et temps avant reprise d'activité, tout cela a
une influence sur le recovery model.

Cdlt,
--
TG2K.
olivier
Le #16978281
Bonjour,

Merci pour ces info, pour repondre à votre question, il s'agit d'insertion
uniquement.
Insertion massive pendant la nuit, puis insertion par les utlisateurs
pendant la journée.

Je vais jeter un oeil sur le Bulk logged".

Merci

Olivier


"TG2K"
Bonjour,

On 14 déc, 10:19, "olivier"
Nous avons un programme qui fait des insertions massive dans sharepoint
(5000 à 6000 par nuit) et il semble que depuis quelques jours les
performances se soient completement écroulées (le temps d'insertion a
progressivement été multiplié par 10 depuis le debut)



Sans maintenance SQL, en effet, c'est possible et même probable. Y a-t-
il suppression puis insertion, ou simple insertion ?

Y a t-il des procedures de maintenance au niveau de la base SQL qui
permetteraient d'optimiser l'insertion dans la base ?



Regardez la taille de vos fichiers de base de données:
- les MDF (data)
- les LDF (transaction logs)
Je parie pour ces derniers que leur taille vous intriguera si
effectivement vous réalisez des opérations "en masse" de cette
envergure.

Agir "en masse" comme vous le faîtes me pousse à vous recommander
l'usage (dans SQL) du mode de recovery "Bulk logged" pour les bases
concernées (Options). Si vous n'êtes pas très au fait de ces
possibilités, je vous invite à vous renseigner tout de même avant
d'agir (mot clé bulk logged sur Google, et un bon dba -ce qui n'est
pas mon cas- devraient faire l'affaire).
Réfléchir avant à votre méthode de backup et restore, perte de données
maximale admissible, et temps avant reprise d'activité, tout cela a
une influence sur le recovery model.

Cdlt,
--
TG2K.
TG2K
Le #16978271
On 14 déc, 11:41, "olivier"
Insertion massive pendant la nuit, puis insertion par les utlisateurs
pendant la journée.



Envisagez également de vérifier le paramétrage "auto-growth" de vos
bases de données, qu'il s'agisse des data (MDF) ou des transaction
logs (LDF), regardez entre la veille et le lendemain quelle est la
croissance des fichiers, et placez comme paramètre de croissance une
valeur au moins équivalente, ça évitera les multiples "auto-growth" de
1Mo ou 10% comme c'est souvent le cas par défaut. C'est très coûteux
en temps SQL, en plus de fragmenter (sur le disque physique) les
fichiers SQL, et donc pénalisant à tous points de vue.

Je vais jeter un oeil sur le Bulk logged".



En gros, il faut comprendre que si le backup de votre ferme SPS est
effectué avec SPSBackup (batch nocturne ?), les transaction logs SQL
ne vous seront d'aucune utilité (seules les data sont sauvegardées).
Dans ce cas, le "bulk logged" est tout à fait envisageable. La source
"fiable" d'infos sur le sujet est le technet MS
(technet.microsoft.com). Il me semble qu'il y a quelques pages sur ce
sujet dans le contexte Sharepoint (2007, mais 2003 a en gros les mêmes
contraintes vu de SQL).
Plus techniquement, le "bulk logged" implique que seules les
transactions SQL "tagguées" bulk sont journalisées (BULK INSERT,
etc...), pas les autres. Du coup, le transaction log n'enregistre pas
grand chose. Très utile dans un contexte de migration ou de
traitements massifs, qui font rapidement exploser les volumes SQL.

--
TG2K
Publicité
Poster une réponse
Anonyme