bugs dans les tables

Bonjour,

nous avons actuellement un site intranet qui nous sert de logiciel de gestion/commerciale.. oui je sais c'est risible lol mais la réalité est là.

Le site en lui-même fonctionne très bien et il est attaché à une base de donnée située sur SQL server (version anglaise - nous n'avons pas l'intention de mettre une version française).

Il se trouve que dans cette base de donnée nous avons une table nommée "stock" (notre table "product" contenant plus de 15000 références) et à priori on commencerais à avoir des bugs lorsque cette table n'est pas vidée au bout de 1 à 2 mois. (ce qui nous équivaut plus de 150 000 lignes).

Je voulais savoir quelles étaient les limites d'une table dans SQL server ? Y'a t'il un bug dû à cette limite.. parce qu'on se trouve avec des références ayant une différence de stock de plus de 200 parfois donc cela ne provient pas d'une erreur humaine !

merci pour votre aide

Je crois que 150 000 n'est pas un nombre important, ça peut allez jusqu'à 2 millions d'enregistrement, je crois que le problème est d'ordre applicatif (interface web)

bonjour,

je te remercie pour ta réponse. Mais je me demande comment ça pourrait provenir de l'interface web vu que le stock est nickel pendant quelques semaines... surtout que lorsque l'on fait l'inventaire, on rentre jusqu'à 15000 lignes d'un seul coup ! 8O

Bonjour,

Tout dépend de la taille affectée au fichier mdf de ton serveur SQL et de la possibilité d'extension du fichier.
De plus, je te conseille de regarder l'espace disque restant sur ton serveur et de faire des troncatures régulière de ton journal de transaction.

Bonjour,

La seule limite de taille c'est celle du disque. Il n'y a pas de limite de nombre de lignes (j'ai des tables de 15 millions de lignes qui ont une intégrité correcte).

Si tu es sous SQL Server 2005, en faisant un clic droit sur la base de données concernée, puis propriétés, et que tu sélectionnes la catégorie fichiers, tu verras quelle est la taille de ton fichier MDF (fichier qui contient les données) et de ton fichier LDF (c'est le journal de transactions).
Tu peux également voir à quelle quantité d'espace qu'ils peuvent être amené à grossir (en %) une fois la capacité atteinte.

N'y-a-t-il pas de processus qui tournent tous les mois ... est-ce que cette table est indexée ? S'il y a beaucoup de requêtes dessus et qu'elle ne l'est pas ou qu'elle l'est mal, tu peux avoir des deadlocks et certaines transactions ne se terminent pas...

Donne-nous plus de détails :P

Quelle version de SQL ?
2000 Entrprise ?
2000 Standard ?
2000 MSDE ?
2005 64 bits
2005 Enterprise ?
2005 Standard
2005 Workgroup ?
2005 ZExpress ?
2005 CE ?

Quel niveau de patch ???

Commençons par le commencement !

A +

Bonjour,

Microsoft SQL Enterprise Manager
Microsoft Corporation
Version: 8.0

dernière version : SQL 2000 service pack 3


espace alloué : 4001 Mb - 10%
fichier transaction : 71769 Mb

par contre je ne me souviens plus si les tables sont indexées.

Il faudrait peut être commencer à faire du ménage dans votre journal de transaction.
Quel est le taux d'occupation de vos disques ?

A +

le disque fait 465 go et il a encore 357 go d'espace disque. donc je ne crois pas que cela provienne de là, de plus, les journaux de transaction sont supprimés au bout de 2 jours il me semble (on a déjà eu le pb de l'espace disque saturé à cause des journaux)

Citation:

---

les journaux de transaction sont supprimés au bout de 2 jours

---

Supprimés ???

Comment faites vous cela ???

Parce que la suppression des JT est une opération dangereuse !

A +

autant pour moi je me trompe c'était les fichiers log d'exchange que l'on faisait supprimé au fur et à mesure. :mouarf:


comment je peux faire pour faire du ménage dans le fichier de transaction ? parce que je pense qu'il n'a jamais été nettoyé.

Citation:

---

Envoyé par Riwalenn

Je voulais savoir quelles étaient les limites d'une table dans SQL server ? Y'a t'il un bug dû à cette limite.. parce qu'on se trouve avec des références ayant une différence de stock de plus de 200 parfois donc cela ne provient pas d'une erreur humaine !

---

Ca provient nécessairement d'une erreur humaine ou d'un bug applicatif (code client ou code SQL). Il n'y a pas de modification des données sauvages par SQL Server, il n'y a aucun bug de ce type dans le code de SQL Server.

Je confirme ce que dit rudi il n'y a plus de bug connu au niveau SQL Server depuis des lustres dans les différentes versions de code SQL et certainement pas de suppression ou moidification parasite. Cela provient donc forcément de l'applicatif.

Pour les journaux de transactions (a ne pas confondre avec des journaux de log...) lire :
http://sqlpro.developpez.com/cours/sqlserver/log/

A +

Bonjour,

je te remercie pour le lien... je pense sincérement que c'est une erreur applicative et non humaine.. s'il n'y avait pas autant d'écart et surtout sur des produits que parfois l'on ne reçoit pas pendant 6 mois et qui ont donc la même quantité depuis au moins 2 ans, j'aurais été d'accord pour le côté humain.

Croyez bien que j'ai beaucoup réfléchi aux causes de ces écarts avant de poster. Pour moi soit le site intranet soit la bdd posaient problème.

Donc on en revient à ce foutu intranet. De toute manière avec mon collègue nous avons proposé au boss de refaire ce site en PHP et donc de revoir tout le code.. il y a trop d'interrogations, trop d'erreurs en suspens...

de toute manière si c'est applicatif, je ne peux rien y faire, je ne m'y connais pas assez en ASP.

merci quand même, je vais lire avec attention le lien que tu m'as apporté.
:king:

bon j'ai trouvé le fichier log et effectivement il est un peu lourd (70go).... je voulais savoir s'il était possible de réduire la taille d'un fichier log déjà utilisé surtout que ce fichier est assez lourd mais surtout que la base est utilisée toute la journée ?

C'est un peu hors-sujet mais si tu maîtrise le PHP tu n'auras aucun problème avec l'ASP... c'est sensiblement la même philisophie, et la syntaxe ne devrait pas te poser de problème bien longtemps si tu as dejà fait un peu de VB

Citation:

---

Envoyé par Riwalenn

bon j'ai trouvé le fichier log et effectivement il est un peu lourd (70go).... je voulais savoir s'il était possible de réduire la taille d'un fichier log déjà utilisé surtout que ce fichier est assez lourd mais surtout que la base est utilisée toute la journée ?

---

Penche-toi sur DBCC SHRINKFILE.
Cf l'article de sqlpro, ou http://www.developpez.net/forums/sho...d.php?t=166895

Bonjour,

Si cela est très très urgent tu peux faire DBCC SQLPERF(LOGSPACE) pour voir combien le ficher de log te prend sur disque, et le pourcentage d'occupation du log, puis DBCC SHRINKFILE 'nomLogiqueDuLogDeTransaction'.

On peut trouver le nom logique du log de transaction en faisant un clic droit sur la base de données concernée, puis en sélectionnaint l'option "Files" dans le volet de gauche :P

ne pas sous tailler le journal de transaction (ce n'est pas un vulgaire fichier de "log") mais le purger en faisant des sauvegardes régulières.

Si vraiment trop grand alors lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/log/

A +

je ne comprends pas alors, tu dis dans ton article :

Citation:

---

De même un fichier de transaction ridiculement petit entrainera des performances notablement dégradées. Inversement, une grande taille n'affecte pas les performances du fait qu'il est écrit en séquentiel.

---

Ce qui signifierai que je ne devrais pas baisser la taille de mon fichier log, bien au contraire si je suis la logique de ton article !

A priori 7go, serait une taille idéale.