Discussion :

[bambino3996]

Bonjour,

Je rencontre des gros problèmes de performances sur ma base de données.
Surtout les des créations/insertion/update/alter (les lectures sur la base s’exécutent bien rapidement par contre).

Je souhaiterait désactiver les logs sur certaines tables (comme sur du oracle par exemple) mais après de nombreuses recherches pour corriger ce problème de performances il semblerait qu'avec sql server soit les logs sont activées sur toute la base soit sur rien.

Ensuite j'ai lu des choses concernant des défragmentations régulières de la base pour retrouver de meilleures performances etc... mais ce n'est pas envisageable dans mon cas.

Connaîtriez-vous une solution (si possible des actions définitives et non pas des actions a faire de façon régulières sur ma base) pour améliorer les performances d'écriture sur ma base ?

Merci d'avance pour vos conseil et votre aide.

[elsuket]

Bonjour,

Je souhaiterait désactiver les logs sur certaines tables (comme sur du oracle par exemple) mais après de nombreuses recherches pour corriger ce problème de performances il semblerait qu'avec sql server soit les logs sont activées sur toute la base soit sur rien.

Une telle chose n'est pas possible pour les raisons que j'ai évoquées ici.

Je ne comprends même pas comment un fournisseur de logiciel peut qualifier son moteur de bases de données de relationnel sans garantir l'ACIDité des données.

Ensuite j'ai lu des choses concernant des défragmentations régulières de la base pour retrouver de meilleures performances etc... mais ce n'est pas envisageable dans mon cas.

Pouvez-vous nous expliquer pourquoi ce n'est pas possible ?
Je ne sais pas combien de fois j'ai entendu cet argument soutenu par des arguments tout aussi démontables.
Donc je n'ai pas dit que je maintenais les index, et un jour quelqu'un se rend compte "ho pu*ain ça turbine !"

Connaîtriez-vous une solution (si possible des actions définitives et non pas des actions a faire de façon régulières sur ma base) pour améliorer les performances d'écriture sur ma base ?

A part la qualité de votre modèle, de vos index, et la maintenance de ceux-ci avec les statistiques de colonne, vous pouvez voir pour du stockage plus rapide.

A mon avis c'est plutôt :

- un défaut de maintenance (le fait de ne pas maintenir les index est une absurdité qui aboutit de toute façon à un gaspillage d'espace du cache de données)
- ou alors vous faites peut-être trop joujou avec TempDB avec des tables temporaires et des variables de type table, et TempDB ne dispose pas de plusieurs fichiers de données
- il y a peut-être trop d'index sur les tables sur lesquelles vous effectuez votre mise à jour.

Malheureusement dans le DDL complet de la table et un descriptif un peu plus complet de ce que vous tentez de faire, de même que votre architecture physique (à savoir partitionnement de tables et répartition des fichiers sur des axes physiques distincts), il va être difficile de vous aider plus précisément.

@++

[bambino3996]

Pour vous donner des informations supplémentaires il s'agit d'un progiciel qui fonctionne beaucoup avec des tables temporaires.

La base de données est créée par ce progiciel.

Je n'ai donc pas la main sur les requêtes effectuées par le progiciel pour les optimiser.

La finalité est un service fonctionnant 7/24 et donc sans "horaires de nuit" pour programmer des maintenances.

[elsuket]

Pour vous donner des informations supplémentaires il s'agit d'un progiciel qui fonctionne beaucoup avec des tables temporaires.

Décidément, j'ai tapé pas loin.
Le problème avec ce genre de tables, c'est qu'à chaque fois que l'on en crée, on doit accéder à des pages "réservées" qui gèrent l'allocation des pages de données.
Évidemment quand on termine une session, la table est supprimée, donc il faut de nouveau accéder à ces pages d'allocation.
Comme ces pages sont peu nombreuses par fichier, il est évident que de la contention se crée : c'est là votre goulot d'étranglement.

Pouvez-vous nous dire combien de fichiers de données contient votre bases de données TempDB ?
Ces fichiers sont ils répartis sur des axes physiques distincts ?
Est-ce que le fichier du journal des transactions et lui aussi sur un axe physique distinct des fichiers de données ?

@++

[bambino3996]

En fait je me suis mal exprimé, il ne s'agit pas de tables temporaire au sens de tempDB, il s'agit de table classiques créée/utilisées/supprimées à la volée, par session d'utilisation par exemple (je reconnais que ce progiciel à lui même de gros défauts).

Et sinon la base ainsi que les journaux sont sur le même serveur.

[StringBuilder]

Pour réduire au maximum la fragmentation, il y a d'une part la fragmentation de la base, et de l'autre, celle du FS.
J'ai vu des bases avec une extension automatique de 1 Mo par fichier... et des tables réparties dans une dizaine de fichiers.
Résultat, le disque dur n'était qu'une succession de petits fragments de 1 Mo éparpillés au bout de quelques jours, et je serveur mettait 10 secondes à trouver une ligne à partir d'un index unique...
=> Il faut donc privilégier les extensions manuelles au extension automatiques, et procéder plutôt à des extension de l'ordre de la centaine de Mo (ou du Go) : tant pis s'il faut 6 mois pour remplir la place libre, au moins elle ne sera pas fragmentée.

[elsuket]

Et sinon la base ainsi que les journaux sont sur le même serveur.

Oui, mais est-ce que les fichiers de données (si vous n'avez pas changé l'extension, MDF et NDF) et le fichier du journal des transactions (de la même façon, LDF) sont sur des disques physiques distincts ?

En fait je me suis mal exprimé, il ne s'agit pas de tables temporaire au sens de tempDB, il s'agit de table classiques créée/utilisées/supprimées à la volée, par session d'utilisation par exemple (je reconnais que ce progiciel à lui même de gros défauts).

Celui-ci en est en tout cas un qui est assez gros.
Si ces tables stockent des quantités de données conséquentes et qu'elles ne sont pas indexées, alors c'est une lecture de table complète pour chaque requête ...
La seule chose que vous pouvez faire je crois c'est de voir avec l'éditeur du logiciel; autant dire que ce n'est pas gagné ...

Pour réduire au maximum la fragmentation, il y a d'une part la fragmentation de la base, et de l'autre, celle du FS.

Vous n'évoquez ici que la fragmentation externe des fichiers, qui n'est certes pas à négliger.
Je pensais aussi à la fragmentation des index, et aussi au nombre de fichiers virtuels du fichier du journal des transactions, qui ne doivent ni être trop nombreux (pour faciliter les grosses transactions) ni trop peu (car le risque de perte de données s'en accroît d'autant).
Pour en savoir un peu plus, vous pouvez lire le billet que j'ai écrit à ce sujet );

[mikedavem]

En fait je me suis mal exprimé, il ne s'agit pas de tables temporaire au sens de tempDB, il s'agit de table classiques créée/utilisées/supprimées à la volée, par session d'utilisation par exemple (je reconnais que ce progiciel à lui même de gros défauts).

Et sinon la base ainsi que les journaux sont sur le même serveur.

Sans plus d'information cela va être dur de déterminer votre problème.

Est ce un problème de ressources ?
Est ce un problème lié à la conception de vos requêtes ?

Est ce que la configuration de votre système est optimale ? Par exemple est ce que votre antivirus a bien les exceptions activés sur vos fichiers de bases de données (mdf, ldf et ndf) en lecture et en écriture ?

...

++

[Glouferu]

Par exemple est ce que votre antivirus a bien les exceptions activés sur vos fichiers de bases de données (mdf, ldf et ndf) en lecture et en écriture ?

Très bonne remarque, j'ai eu le cas il y a 2 semaines avec G-Data... et je peux vous assurer que ça pourri les perfs !