Optimisation/verification Sage Sql 100

Bonjour à tous,

nous avons 5 base SQL sage 100 i7 8.50, la taille MDF vont de 1.2 à 1.7 giga avec sql 2008 r2 Std
Utilisation en TSE/citrix windows 2008 r2

Les comptable me signale par moment des ralentissement dans la compta sage ( et pas dans notre SI qui à sa base SQL sur le meme serveur)

J'aurai voulu avoir vos retours sur les paramètre à vérifier en 1er dans SQL server pour chacune des base, pour voir si les pre-requis/best pratice sont bien appliqué sur toutes les base Sql de la compta Sage.

Et une autre question , combien de temps devons nous garder les archives de nos base sql compta ? car pour société j'ai les archives qui commence à 2006 à 2012

merci d'avance pour vos retours

guigui69

Bonjour,

Regardez ici pour la base SQL.

Pour le délai de conservation, il me semble que c'est 5 ans, et qu'un contrôle remonte sur 3 ans maxi (mais il vaudrait mieux un avis complémentaire...)

HTH,

Merci, je regarde ca lundi. pour le SQL

(Autre question) au niveau duclient Sage, il est optimisé pour les environnement 64 bit multi processeur?

guigui69

@guigui69,

Non, application 32bits, monothread à ma connaissance...

Cordialement,

Bonjour asr31,

quand tu parles accroissement c'est bien ca:


Donc normalement c'est bien réglé comme ceci non ?



autre question, je ne comprend pas cette ligne:

D'autre part, avez-vous un plan de maintenance SQL qui inclut la défragmentation / reconstruction des index de façon régulière ?

Bonjour,

Yes, c'est bien ça.
On sort là un peu du domaine SAGE 100.
Il vaut mieux regarder les forums Miscrosoft SQL.

Cordialement,

D'accord,
donc au niveau défragmentation / reconstruction des index il n'y pas de regle définit cpour sage ?

Bonjour,

Pour les 10% chacun voit midi à sa porte, au regard des volumes pourquoi pas, mais je reste partisan d'un accroissement par pas fixe. La taille initiale du journal est trop petite par rapport à celle du fichier de données, tabler sur 1/4 mini.

Si c'était ma base, je partirais sur :
MDF : 2048 / Accroissement 512
LDF : 512 / Accroissement 128 ou 256

L'idéal étant que l'accroissement n'ait jamais lieu.

Pour les index, toujours en regard des volumes, reconstruction hebdomadaire mini.
Pour le reste de la semaine, à tester, mais en ce qui me concerne defrag et mise à jour des stats quotidiennes sur la plupart des mes déploiements.

HTH,

D'accord,

Pour mettre en place la reconstruction index et defrag, c'est compliquer ? il faut avoir des compétences en SQL ? Connaitre des tables spécifique ?