Discussion :

[sanach]

bonjour
Comme l'indique le titre, je veux savoir la taille maximal qu'un SQL SERVER 2000 peut gérer, sachant que j'utilise une base de 50 GO.
ainsi que les tailles relatives à SQL server 2005 et 2008.
Merci beuacoup

[Invité]

Visiblement, vous avez passer plus de temps à taper ce message qu'à aller chercher dans google :
http://msdn.microsoft.com/en-us/libr...SQL.90%29.aspx
http://msdn.microsoft.com/en-us/library/ms143432.aspx

Pour 2000, j'ai pas chercher, à vous de faire un minimum d'effort... D'ailleurs c'est une version obsolète.

Et 50 Go pour une bd, de nos jours, c'est petit. Quand c'est gros, on commence à compter en plusieurs centaine de Go voir en Po...

[elsuket]

Bonjour,

Voici pour SQL Server 2000 : 1,048,516 TB, soit 1 exa-octet. ça ça fait un paquet d'INSERT

@++

[sanach]

Visiblement, vous avez passer plus de temps à taper ce message qu'à aller chercher dans google :
http://msdn.microsoft.com/en-us/libr...SQL.90%29.aspx
http://msdn.microsoft.com/en-us/library/ms143432.aspx

Pour 2000, j'ai pas chercher, à vous de faire un minimum d'effort... D'ailleurs c'est une version obsolète.

Et 50 Go pour une bd, de nos jours, c'est petit. Quand c'est gros, on commence à compter en plusieurs centaine de Go voir en Po...

Merci pour votre réponse. je détaille encore plus mon problème, j'utilise SQL SERVER 2000 avec une base de 50 GO, l'accès au serveur est très lent, et ça prend beaucoup du temps pour de simples requêtes (j'utilise CEGID comme ERP).je n'ai pas trouvé d'explication que dire que la base est grande par rapport à la version 2000 de SQL SERVER et c'est pour ce là j'ai posé ma question. avez vous une idée sur la source du problème, peut être que ce soit une mal configuration de sql server ou autre j'en sais rien.
Merci pour votre aide

[Invité]

je n'ai pas trouvé d'explication que dire que la base est grande par rapport à la version 2000 de SQL SERVER et c'est pour ce là j'ai posé ma question.

Et bien non!
Il reste à savoir si vous avez des tables qui contiennent des millions de lignes et si la structure de la bd est correct et si les traitements se font suivant les règles de l'art ou pas.
Est-ce qu'il y a beaucoup de code avec des curseurs dedans?

[sanach]

Merci pour vous deux, j'espère avoir de nouvelle réponse..

[sevyc64]

[Mode Gros Troll poilu]

(j'utilise CEGID comme ERP)

Cherchez l'erreur

[/Mode Gros Troll poilu]

La lenteur peut venir de beaucoup de chose.
Coté bases de données, mauvaise conception, index, clé primaire et FK mal placées, etc .... Malheureusement sur ce point tu ne peux pas agir

Coté serveur, tu as peux être un serveur sur les genoux, pas assez puissants, pas assez de mémoire, trop d'utilisateurs simultanés, trop de requêtes, etc ...

Vérifie déjà tes plans de maintenance. Plusieurs opérations doivent être faites régulièrement en plus des sauvegardes.
Chez un de mes clients, de mettre en place une reconstruction d'index une fois par semaine a suffit à diviser le temps un processus d'import nocturne journalier, par 3.

[elsuket]

Bonjour,

Utilisez ce billet pour voir les index qui *pourraient* faire du bien à votre base de données.
Attention, ne les implémentez pas tous !

Vous pouvez également vous appuyer sur la DMV sys.dm_exec_query_stats pour trouver les requêtes les plus coûteuses, voir leur plan d'exécution, et adresser leurs problèmes de performance

@++

[sanach]

Merci pour toutes vos réponses