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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TG2K
Bonjour,
On 14 déc, 10:19, "olivier" wrote:
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.
Bonjour,
On 14 déc, 10:19, "olivier" <olivier.cordi...@wanadoo.fr> wrote:
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.
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
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" a écrit dans le message de news:
Bonjour,
On 14 déc, 10:19, "olivier" wrote:
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.
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" <ElGibs@gmail.com> a écrit dans le message de news:
217527fc-52c1-4d19-8fe0-3c29b2ceeecf@e23g2000prf.googlegroups.com...
Bonjour,
On 14 déc, 10:19, "olivier" <olivier.cordi...@wanadoo.fr> wrote:
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.
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" a écrit dans le message de news:
Bonjour,
On 14 déc, 10:19, "olivier" wrote:
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
On 14 déc, 11:41, "olivier" wrote:
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
On 14 déc, 11:41, "olivier" <olivier.cordi...@wanadoo.fr> wrote:
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.
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.
