{SQL Server} Copie de base de données
Kyra13
Messages postés
18
Date d'inscription
Statut
Membre
Dernière intervention
-
pretexte Messages postés 9 Date d'inscription Statut Membre Dernière intervention -
pretexte Messages postés 9 Date d'inscription Statut Membre Dernière intervention -
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
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
A voir également:
- {SQL Server} Copie de base de données
- Fuite données maif - Guide
- Base de registre - Guide
- Copie cachée - Guide
- Supprimer les données de navigation - Guide
- Super copie - Télécharger - Gestion de fichiers
3 réponses
Bonsoir,
Effectivement, celà risque de durer un certain temps
Déjà avez-vous un plan de maintenance et d'optimisation des index et des tables. Quelle est la taille réelle du fichier DAT et des fichiers logs actuellement.
De base (sic), on peut déjà améliorer je pense les temps actuels en effectuant une optimisation partielle tous le jours et plus complète le W-E
Au niveau des clients également je pense qu'il devrait avoir moyen d'optimiser. Vous utilisez quoi comme connexion DSN, DNS LESS, OLE DB, SQL Native CLient pour la liaison à la base (depuis le client ou le serveur web ou d'applications intermédiaires) ? . Faites -vous une défragmentation du disque et des fichiers de base + défragmentation de la base elle-même et des index ? Est ce que vos clés et vos index ont été etudiés, avez vous fait un état des transactions... etc. (juste un exemple : ton client consulte tes données de la veille peut-être il faut un code client et une date. La clé et/ou les index sont comment : Date Code client uniquement (pour facilier les batchs de nuit), il y a aussi code client date (c'est mieux) mais si la date est en Ascendant et non en Descendant, et si dans la base, il ya les données depuis 1950, bonjour les temps le matin. Donc le resenti de tes clients de dépend pas peut-être pas de la mise en place d'une solution physique d'un nouveau serveur mais d'une étude d'optimisation globale assortie de scripts auto.
Ceci étant, si l'on reste au niveau de ta problématique, il y a 3 solutions
1) Sauvegarde puis restauration via backup restore, en fonction du temps et de l'optimisation, c'est peut-être jouable, mais il faudra savoir les heures de démarrage et d'arrêt de tes procédures de nuit puis les heures de reprise. (Inutile de penser à Zipper pour améliorer les temps de transferts, le zip ne marche pas sur 63 go)
2) En fin d'intégration, arrêt de la base sur votre station puis sur le système 1, copie simple des fichiers data et logs de la station vers système 1, redémarrage sur système1 (celà marche avec qq précautions )
3) processus de replication des bases entre elles. La aussi, cependant la notion des temps est importante et ce sera peut-être plus compliqué.
Dans tous les cas, il faut une liaison à 1 Gigabit et si possible dédiée pour accélérer les temps (donc 2 cartes réseaux sur chaque serveur /station)
A ta disposition éventuelle pour un audit
A+
Effectivement, celà risque de durer un certain temps
Déjà avez-vous un plan de maintenance et d'optimisation des index et des tables. Quelle est la taille réelle du fichier DAT et des fichiers logs actuellement.
De base (sic), on peut déjà améliorer je pense les temps actuels en effectuant une optimisation partielle tous le jours et plus complète le W-E
Au niveau des clients également je pense qu'il devrait avoir moyen d'optimiser. Vous utilisez quoi comme connexion DSN, DNS LESS, OLE DB, SQL Native CLient pour la liaison à la base (depuis le client ou le serveur web ou d'applications intermédiaires) ? . Faites -vous une défragmentation du disque et des fichiers de base + défragmentation de la base elle-même et des index ? Est ce que vos clés et vos index ont été etudiés, avez vous fait un état des transactions... etc. (juste un exemple : ton client consulte tes données de la veille peut-être il faut un code client et une date. La clé et/ou les index sont comment : Date Code client uniquement (pour facilier les batchs de nuit), il y a aussi code client date (c'est mieux) mais si la date est en Ascendant et non en Descendant, et si dans la base, il ya les données depuis 1950, bonjour les temps le matin. Donc le resenti de tes clients de dépend pas peut-être pas de la mise en place d'une solution physique d'un nouveau serveur mais d'une étude d'optimisation globale assortie de scripts auto.
Ceci étant, si l'on reste au niveau de ta problématique, il y a 3 solutions
1) Sauvegarde puis restauration via backup restore, en fonction du temps et de l'optimisation, c'est peut-être jouable, mais il faudra savoir les heures de démarrage et d'arrêt de tes procédures de nuit puis les heures de reprise. (Inutile de penser à Zipper pour améliorer les temps de transferts, le zip ne marche pas sur 63 go)
2) En fin d'intégration, arrêt de la base sur votre station puis sur le système 1, copie simple des fichiers data et logs de la station vers système 1, redémarrage sur système1 (celà marche avec qq précautions )
3) processus de replication des bases entre elles. La aussi, cependant la notion des temps est importante et ce sera peut-être plus compliqué.
Dans tous les cas, il faut une liaison à 1 Gigabit et si possible dédiée pour accélérer les temps (donc 2 cartes réseaux sur chaque serveur /station)
A ta disposition éventuelle pour un audit
A+
Bonjour,
Je ne sais pas comment vous pouvez répondre, alors que nous ne savons rien de ce qui permettrait d'avoir une vrais stratégie.
Alors pour ma part ayant réglé un tel probléme, je me permets une liste de questions (celles qui nous ont amené chez nous a trouver un rendement super)
1) sous quel protocol les infos sont envoyées. FTP etc... upload etc ...
2) avec quel format de fichier SQL tableurs etc ...
3) de quel heure a quelle heure (ensuite les fichiers en retard seront traités le lendemain)
4) a quelle heure le traitement commence
5) la base doit'elle étre lisible (consultable pendant traitement)
6) la base doit'elle étre modifiable (par les visiteur la nuit pendant traitement)
7) Combien d'enregistrement par nuit ? (pas la taille on s'en moque)
Voila avec cela se sera facile de répondre !
Je ne sais pas comment vous pouvez répondre, alors que nous ne savons rien de ce qui permettrait d'avoir une vrais stratégie.
Alors pour ma part ayant réglé un tel probléme, je me permets une liste de questions (celles qui nous ont amené chez nous a trouver un rendement super)
1) sous quel protocol les infos sont envoyées. FTP etc... upload etc ...
2) avec quel format de fichier SQL tableurs etc ...
3) de quel heure a quelle heure (ensuite les fichiers en retard seront traités le lendemain)
4) a quelle heure le traitement commence
5) la base doit'elle étre lisible (consultable pendant traitement)
6) la base doit'elle étre modifiable (par les visiteur la nuit pendant traitement)
7) Combien d'enregistrement par nuit ? (pas la taille on s'en moque)
Voila avec cela se sera facile de répondre !
