Discussion :

[Kyra13]

Bonjour,

Dans l'entreprise où je suis, nous travaillons sur une base de données SQL Server 2005.
La nuit, nous recevons des fichiers que nous intégrons automatiquement et des requête SQL sont lancées à des heures précises. Tout cela dans le but que nos clients puissent consulter leur données mises à jour le matin.
Nous n'avons qu'un serveur, donc les requêtes SQL sont lancés sur ce dernier et si un client vient à se connecter le matin, il se rendra compte que le site est "lent".

Ce que nous souhaitons faire, c'est acheter une station de travail qui s'occuperai de toutes les mises à jours et une fois cela terminé : copier la base de données sur le serveur.

Là où je me pose des questions c'est :
- Comment faire pour copier une base de données. Je me doute qu'un simple copier-coller est trop facile, mais peut etre avec la fonction back-up...
- Quel temps ça va prendre, sachant que ma base de données pèse 63Go ?

Merci de m'avoir accordé un peu de votre temps à lire mon problème, en espérant avoir quelques réponses je vous souhaite une bonne journée !


Marlène

[SQLpro]

Votre façon de faire n'est certainement pas la bonne.... Rajouter une "copie" sans traiter les problème de lenteur ne fera que rajouter une couche supplémentaire de process pour la "copie". Vous feriez mieux de vous attaquer à la problématique de lenteur :
1) le serveur est-il redémaré ? Si oui, ne pas le faire ! Un SGBDR comme SQL Server doit impérativement travailler 24h/24 7J/7...
2) désactivez vous le maximum d'index avant de faire vos insertions ? Si non, jetez un coup d'œil à ce papier : http://sqlpro.developpez.com/cours/s...ivation-index/
3) défragmentez vous vos index quotidiennement ?

63 Go c'est du pipi de chat en terme de volumétrie... Encore faut-il un serveur correctement dimensionné. Quellles sont les caractéristiques physiques de votre serveur (RAM, CPU, DISQUe) ?

A +

[Kyra13]

Tout d'abord, merci pour votre rapide réponse.

1) Le serveur tourne 24h/24h et 7j/7j, il n'est redémarré que pour les mises à jour de windows.

2) Dans le lien que vous avez mis, ils stipulent que c'est inutile pour SQL Server 2005 : "En effet depuis la version 2005, MS SQL Server possède un ordre qui rend caduque cet article et qui permet de désactiver un index quel qu'il soit "

3) Non à l'évidence, car je ne comprends pas le sens de votre phrase.

La configuration du serveur :
Intel Xeon 3040 1,86Ghz
2 Go de RAM

Mon problème ne vient pas de la lenteur des requêtes.
Le problème vient du fait que nous recevons des fichiers en début de matinée (5-7h) et nous devons les intégrer rapidement. Nous ne pouvons changer cela, car travaillant dans le milieu du transport il nous faut des informations récentes. C'est pourquoi je trouvée mon idée intéressante. Bloquer le serveur très peu de temps pour copier la base de données au lieu de la rendre lente le temps des mises à jour.

Le planning serait le suivant :
- Récupération des fichiers (fin 7h)
- Lancement des requêtes (de 7h à 9h30)
- Copie de la base de données (Durée non estimée)

Qu'en pensez-vous ?

[SQLpro]

2 GO de RAM, c'est extrêmement faible pour une base de 63 Go.... Grosso modo j'aurais mis au minimum 4 Go, mais plutôt 6 A 16 Go, tout dépend depuis quand remonte votre historique et la fréquence d'utilisation de votre base.
Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p5...2-bits-et-awe/

N'oubliez jamais que dans un SGBDR toutes les opérations s'effectuent en mémoire. S'il n'y a pas assez de RAM, alors il y a une forte utilisation du disque qui par nature est mille à un million de fois plus lent !

D'autre part, la défragmentation des index permet de reconstruire ces derniers car chaque INSERT / UPDATE / DELETE gruyérise la structure qui stocke les index. Pour comprendre pourquoi et comment y remédier, lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/optimis...ntenanceIndex/
En principe vous devriez reconstruire vos index une fois par nuit....

Enfin, pour accélérer les insertions il est indispensable que vos fichiers de la base (données et journal) possèdent une taille suffisamment grande pour absorber la charge transactionnelle et les données pour les quelques années à venir. Par exemple si vos 63 Go sont le fruit de 2 années et considérez que votre serveur va encore vivre 5 ans, alors taillez le fichier de données à 224 Go et celui du JT à 70 Go.
http://blog.developpez.com/sqlpro/p5...fichiers-et-t/

2) Dans le lien que vous avez mis, ils stipulent que c'est inutile pour SQL Server 2005 : "En effet depuis la version 2005, MS SQL Server possède un ordre qui rend caduque cet article et qui permet de désactiver un index quel qu'il soit "

Dans cet article que j'ai écrit, vous pouvez donc faire un ALTER INDEX ... DISABLE avant les insertion, puis un ALTER INDEX REBUILD après, mais en ne touchant à aucun des index sémantique (PRIMARY KEY, UNIQUE...).

Avec ces 3 mesures, vous allez diviser vos temps de réponse à l'insertion de vos fichier dans un rapport que j'estime à vu de nez de 5 à 25 !

Sachez qu'un serveur cela s'administre et que DBA est un métier à part entière nécessitant une solide formation....

A +