Ca fait 4 fois dans la journée que je répare la table POST (qui ne supportes plus pleins de choses)
Sa taille est de 1.434.443 entrées. (1 43 44 43)
TOUS les messages du forum....
et en grattant un peu.
|
Citation: |
|
|
|
|
There is a limit of
|
Citation: |
|
|
|
|
(232)2 (1.844E+19) |
|
|
|
|
- La copie ne marchant pas - 2 puissance 32 au carré et 1.844 fois 10 puissance 19 (si j'ai tout compris, suis pas un gros matheux) rows in a MyISAM table |
|
|
|
|
Bien que l'on soit loin de ces nombres, la base est vieille, (donc les suppressions doivent aussi être dedans, mais non visibles) on tape peut être dans un mur de limitation du serveur. (on est arrivé au bout des capacités du serveur tel qu'il a été conçu à l'époque).
-----
En cherchant des limitations existantes je tombe sur des messages, (génériques SQL, pas forcément sur notre profil serveur, mais qui restent valides)
|
Citation: |
|
|
|
|
cela dépend ton serveur
avec SQLserveur2005 entreprise (pas de pb)
avec sql2000 entreprise (la garantie microsoft va jusqu'a 8go) mais j'ai eu des bases de 30go sans pb
pour les grosses bases, pense aussi au hardware (RAM,disque rapide, etc...)
et si tu peux, mes les bases tempdb et msdb sur un disque rapide et différent de celui de la base elle-même (idem pour le log)
peux-tu faire des clusters ?
pour Oracle, il faut te dire que je ne connais pas de serveur Oracle (digne de ce nom) qui ne demande pas la présence quasi permanente d'un DBA, alors que pour SQLserveur c'est pas obligatoire. Bien sur Oracle c'est autre chose... |
|
|
|
|
La ram et les disque rapide c'est le gros point noir que l'on a chez OVH - (on peut avoir plus de ram ailleurs, mais je ne sais pas si les disques sont plus rapides)
(la sauvegarde de la base que je viens de faire (fichier .sql) est de 398 Mo...