Restauration SQL2005
Arkkan
Messages postés
2
Date d'inscription
jeudi 13 août 2009
Statut
Membre
Dernière intervention
14 août 2009
-
13 août 2009 à 11:36
dymsbess Messages postés 56 Date d'inscription mercredi 29 septembre 2004 Statut Membre Dernière intervention 4 janvier 2010 - 25 déc. 2009 à 12:53
dymsbess Messages postés 56 Date d'inscription mercredi 29 septembre 2004 Statut Membre Dernière intervention 4 janvier 2010 - 25 déc. 2009 à 12:53
A voir également:
- Aucun jeu de sauvegarde n'a été sélectionné pour être restauré
- La clé de recherche n'a été trouvée dans aucun enregistrement - Forum Visual Basic 6
- Sauvegarde et restauration SQLServer - Forum SQL
- Une exception a été levée par l'initialiseur de type pour ✓ - Forum VB.NET
- Le jeu de sauvegarde contient la sauvegarde d'une base de données qui n'est pas la base de données ✓ - Forum Delphi / Pascal
- Un point d'arrêt a été atteint ✓ - Forum C
4 réponses
nivsql
Messages postés
159
Date d'inscription
lundi 22 juin 2009
Statut
Membre
Dernière intervention
14 décembre 2010
1
13 août 2009 à 20:05
13 août 2009 à 20:05
Non Désolé. De plus tu mélange pas mal de notions distinctes.
"Tablespace" n'a pas d'existance au sens SQL Server, c'est une notion qui vient d'oracle et qui correspond en SQL Server aux "Groupe de fichier".
Par ailleur ces notion correspondent a des espaces de stockage LOGIQUE (et non physique) il n'existe pas reelement et encore moins sous la forme d'un fichier .mdf. Ces "Groupe de fichier" sont constituer de 1 à plusieurs fichiers. 1 seul (le fichier maitre du "Groupe" PRIMARY) porte l'extention .mdf, les autres portant l'extention .ndf.
Le backup prend une image fidele de la base a l'instant T de la sauvegarde et la restaurera en l'etat, y comprit les metadonnées de la base, entre autre : les utilisateur, les fichiers etc. Créer des nouvelles metadonnées pendant la restauration est assez hasardeux et d'ailleur la plus part des editeur (Microsoft comprit) ne le permettent pas sauf pour déplacer un fichier lors d'une restauration.
"Tablespace" n'a pas d'existance au sens SQL Server, c'est une notion qui vient d'oracle et qui correspond en SQL Server aux "Groupe de fichier".
Par ailleur ces notion correspondent a des espaces de stockage LOGIQUE (et non physique) il n'existe pas reelement et encore moins sous la forme d'un fichier .mdf. Ces "Groupe de fichier" sont constituer de 1 à plusieurs fichiers. 1 seul (le fichier maitre du "Groupe" PRIMARY) porte l'extention .mdf, les autres portant l'extention .ndf.
Le backup prend une image fidele de la base a l'instant T de la sauvegarde et la restaurera en l'etat, y comprit les metadonnées de la base, entre autre : les utilisateur, les fichiers etc. Créer des nouvelles metadonnées pendant la restauration est assez hasardeux et d'ailleur la plus part des editeur (Microsoft comprit) ne le permettent pas sauf pour déplacer un fichier lors d'une restauration.
Arkkan
Messages postés
2
Date d'inscription
jeudi 13 août 2009
Statut
Membre
Dernière intervention
14 août 2009
14 août 2009 à 10:16
14 août 2009 à 10:16
Merci de ta réponse.
Effectivement pour le TableSpace j'ai confondu avec Oracle (plus souvent dessus que SQL)
En fait le but de cette manip' était d'améliorer les perfs de la base, celle-ci commencant à "ramer".
La BDD en question a été crée sous un seul fichier (Primary) au lieu de 5 (standard normalement adopté dans cette entreprise).
Je vais donc explore une nouvelle voie pour soulager mon serveur. ;)
Effectivement pour le TableSpace j'ai confondu avec Oracle (plus souvent dessus que SQL)
En fait le but de cette manip' était d'améliorer les perfs de la base, celle-ci commencant à "ramer".
La BDD en question a été crée sous un seul fichier (Primary) au lieu de 5 (standard normalement adopté dans cette entreprise).
Je vais donc explore une nouvelle voie pour soulager mon serveur. ;)
nivsql
Messages postés
159
Date d'inscription
lundi 22 juin 2009
Statut
Membre
Dernière intervention
14 décembre 2010
1
14 août 2009 à 11:23
14 août 2009 à 11:23
Tu peux toujours créer un ou plusieurs nouveau FILEGROUPE et deplacer les objets de ta base dessus Index Cluster et Table Heap sur un FileGroupe DATA et les index non Cluster sur un FileGroupe INDEX. Cela dis c'est loins d'etre la premiere chose a faire ramer une base SQL Server loins de la. Meme si la séparation est toujours une bonne chose pour des question de fragmentation dans les pages de la base je ne commencerais pas par regarder de ce coté la. En effet La pression disk n'est pas la premiere cause de ralentissement, et dans la majorité des cas cette pression disk s'exerce non pas sur les fichiers de données mais sur le LOG !
Je chercherais plutot une pression mémoire ou une pression processeur en premier.
Je chercherais plutot une pression mémoire ou une pression processeur en premier.
dymsbess
Messages postés
56
Date d'inscription
mercredi 29 septembre 2004
Statut
Membre
Dernière intervention
4 janvier 2010
1
25 déc. 2009 à 12:53
25 déc. 2009 à 12:53
FAUX ! Si tu veux éviter une fragmentation, il suffit de dimensionner les fichiers de base de données correctement, c'est la base. La fragmentation des pages d'index est imputable au taux de remplissage. Le fait d'avoir n fichiers de base de données permet avant tout de répartir les accès disque.