J'utilise un produit de réplication pour répliquer des fichiers de base de
données entre 2 systèmes. Ce produit effectue un checksum entre la source et
la cible, en se basant entre autres les attributs de date de création et date
heure de dernière modification. La taille est également utilisée.
Je ne connais pas les cas de figure pendant lesquels un fichier MDF (par
exemple) voir son attribut date de modification modifié (hors croissance
automatique de fichier) : ajout de données dans un table, creat/drop d'une
table/index ?
Si quelqu'un a la réponse je le remercie d'avance.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SQLpro [MVP]
Xhork a écrit :
Bonjour,
J'utilise un produit de réplication pour répliquer des fichiers de base de données entre 2 systèmes. Ce produit effectue un checksum entre la source et la cible, en se basant entre autres les attributs de date de création et date heure de dernière modification. La taille est également utilisée.
Je ne connais pas les cas de figure pendant lesquels un fichier MDF (par exemple) voir son attribut date de modification modifié (hors croissance automatique de fichier)
en dehors de ce cas rien sinon l'arrêt redémarrage de SQL Server ou la fermeture de la base par ALTER ... OFFLINE
: ajout de données dans un table, creat/drop d'une
table/index ?
Nullement, les fichiers restent ouvert tout le temps à usage exclusif de MS SQL Server.
Si quelqu'un a la réponse je le remercie d'avance.
Merci.
David C.
Ce n'est d'ailleurs pas du tout une bonne méthode que de penser que la copie de fichier de la base peut servir de solution de réplication. Vous avez toutes les chances que vos fichiers ne servent à rien car il peuvent s'avérer inexploitable...
En effet microsoft ne garantie pas la consistance des bases de données en dehors des procédures sp_detach/sp_attach, du BACKUP / RESTORE ou encore des mécanismes de réplication interne à SQL Server parmi lesquels le log shipping relativement facile à implementer constituerait la meilleure alternative à votre problématique.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Xhork a écrit :
Bonjour,
J'utilise un produit de réplication pour répliquer des fichiers de base de
données entre 2 systèmes. Ce produit effectue un checksum entre la source et
la cible, en se basant entre autres les attributs de date de création et date
heure de dernière modification. La taille est également utilisée.
Je ne connais pas les cas de figure pendant lesquels un fichier MDF (par
exemple) voir son attribut date de modification modifié (hors croissance
automatique de fichier)
en dehors de ce cas rien sinon l'arrêt redémarrage de SQL Server ou la
fermeture de la base par ALTER ... OFFLINE
: ajout de données dans un table, creat/drop d'une
table/index ?
Nullement, les fichiers restent ouvert tout le temps à usage exclusif de
MS SQL Server.
Si quelqu'un a la réponse je le remercie d'avance.
Merci.
David C.
Ce n'est d'ailleurs pas du tout une bonne méthode que de penser que la
copie de fichier de la base peut servir de solution de réplication.
Vous avez toutes les chances que vos fichiers ne servent à rien car il
peuvent s'avérer inexploitable...
En effet microsoft ne garantie pas la consistance des bases de données
en dehors des procédures sp_detach/sp_attach, du BACKUP / RESTORE ou
encore des mécanismes de réplication interne à SQL Server parmi lesquels
le log shipping relativement facile à implementer constituerait la
meilleure alternative à votre problématique.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
J'utilise un produit de réplication pour répliquer des fichiers de base de données entre 2 systèmes. Ce produit effectue un checksum entre la source et la cible, en se basant entre autres les attributs de date de création et date heure de dernière modification. La taille est également utilisée.
Je ne connais pas les cas de figure pendant lesquels un fichier MDF (par exemple) voir son attribut date de modification modifié (hors croissance automatique de fichier)
en dehors de ce cas rien sinon l'arrêt redémarrage de SQL Server ou la fermeture de la base par ALTER ... OFFLINE
: ajout de données dans un table, creat/drop d'une
table/index ?
Nullement, les fichiers restent ouvert tout le temps à usage exclusif de MS SQL Server.
Si quelqu'un a la réponse je le remercie d'avance.
Merci.
David C.
Ce n'est d'ailleurs pas du tout une bonne méthode que de penser que la copie de fichier de la base peut servir de solution de réplication. Vous avez toutes les chances que vos fichiers ne servent à rien car il peuvent s'avérer inexploitable...
En effet microsoft ne garantie pas la consistance des bases de données en dehors des procédures sp_detach/sp_attach, du BACKUP / RESTORE ou encore des mécanismes de réplication interne à SQL Server parmi lesquels le log shipping relativement facile à implementer constituerait la meilleure alternative à votre problématique.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Xhork
Bonjour,
Merci pour votre réponse. Voici quelques éléments qui complètent mon premier post.
- Le système de réplication est Double-Take - SQL Server 2000 est installé de manière identique sur les 2 systèmes - Une instance de la base de données existe sur les 2 systèmes - Elle a été créée de façon similaire dans les 2 environnements - Quand le système de production est actif (entendu sur le plan SQL Server), le second est "dormant". Vice-versa.
Cette technique fonctionne bien.
Ma question portait essentiellement sur les attributs de fichiers.
Mais je suis bien sûr à l'écoute de vos conseils.
David
"SQLpro [MVP]" a écrit :
Xhork a écrit : > Bonjour, > > J'utilise un produit de réplication pour répliquer des fichiers de base de > données entre 2 systèmes. Ce produit effectue un checksum entre la source et > la cible, en se basant entre autres les attributs de date de création et date > heure de dernière modification. La taille est également utilisée. > > Je ne connais pas les cas de figure pendant lesquels un fichier MDF (par > exemple) voir son attribut date de modification modifié (hors croissance > automatique de fichier)
en dehors de ce cas rien sinon l'arrêt redémarrage de SQL Server ou la fermeture de la base par ALTER ... OFFLINE
: ajout de données dans un table, creat/drop d'une > table/index ?
Nullement, les fichiers restent ouvert tout le temps à usage exclusif de MS SQL Server.
> > Si quelqu'un a la réponse je le remercie d'avance. > > Merci. > > David C. >
Ce n'est d'ailleurs pas du tout une bonne méthode que de penser que la copie de fichier de la base peut servir de solution de réplication. Vous avez toutes les chances que vos fichiers ne servent à rien car il peuvent s'avérer inexploitable...
En effet microsoft ne garantie pas la consistance des bases de données en dehors des procédures sp_detach/sp_attach, du BACKUP / RESTORE ou encore des mécanismes de réplication interne à SQL Server parmi lesquels le log shipping relativement facile à implementer constituerait la meilleure alternative à votre problématique.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Bonjour,
Merci pour votre réponse.
Voici quelques éléments qui complètent mon premier post.
- Le système de réplication est Double-Take
- SQL Server 2000 est installé de manière identique sur les 2 systèmes
- Une instance de la base de données existe sur les 2 systèmes
- Elle a été créée de façon similaire dans les 2 environnements
- Quand le système de production est actif (entendu sur le plan SQL Server),
le second est "dormant". Vice-versa.
Cette technique fonctionne bien.
Ma question portait essentiellement sur les attributs de fichiers.
Mais je suis bien sûr à l'écoute de vos conseils.
David
"SQLpro [MVP]" a écrit :
Xhork a écrit :
> Bonjour,
>
> J'utilise un produit de réplication pour répliquer des fichiers de base de
> données entre 2 systèmes. Ce produit effectue un checksum entre la source et
> la cible, en se basant entre autres les attributs de date de création et date
> heure de dernière modification. La taille est également utilisée.
>
> Je ne connais pas les cas de figure pendant lesquels un fichier MDF (par
> exemple) voir son attribut date de modification modifié (hors croissance
> automatique de fichier)
en dehors de ce cas rien sinon l'arrêt redémarrage de SQL Server ou la
fermeture de la base par ALTER ... OFFLINE
: ajout de données dans un table, creat/drop d'une
> table/index ?
Nullement, les fichiers restent ouvert tout le temps à usage exclusif de
MS SQL Server.
>
> Si quelqu'un a la réponse je le remercie d'avance.
>
> Merci.
>
> David C.
>
Ce n'est d'ailleurs pas du tout une bonne méthode que de penser que la
copie de fichier de la base peut servir de solution de réplication.
Vous avez toutes les chances que vos fichiers ne servent à rien car il
peuvent s'avérer inexploitable...
En effet microsoft ne garantie pas la consistance des bases de données
en dehors des procédures sp_detach/sp_attach, du BACKUP / RESTORE ou
encore des mécanismes de réplication interne à SQL Server parmi lesquels
le log shipping relativement facile à implementer constituerait la
meilleure alternative à votre problématique.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci pour votre réponse. Voici quelques éléments qui complètent mon premier post.
- Le système de réplication est Double-Take - SQL Server 2000 est installé de manière identique sur les 2 systèmes - Une instance de la base de données existe sur les 2 systèmes - Elle a été créée de façon similaire dans les 2 environnements - Quand le système de production est actif (entendu sur le plan SQL Server), le second est "dormant". Vice-versa.
Cette technique fonctionne bien.
Ma question portait essentiellement sur les attributs de fichiers.
Mais je suis bien sûr à l'écoute de vos conseils.
David
"SQLpro [MVP]" a écrit :
Xhork a écrit : > Bonjour, > > J'utilise un produit de réplication pour répliquer des fichiers de base de > données entre 2 systèmes. Ce produit effectue un checksum entre la source et > la cible, en se basant entre autres les attributs de date de création et date > heure de dernière modification. La taille est également utilisée. > > Je ne connais pas les cas de figure pendant lesquels un fichier MDF (par > exemple) voir son attribut date de modification modifié (hors croissance > automatique de fichier)
en dehors de ce cas rien sinon l'arrêt redémarrage de SQL Server ou la fermeture de la base par ALTER ... OFFLINE
: ajout de données dans un table, creat/drop d'une > table/index ?
Nullement, les fichiers restent ouvert tout le temps à usage exclusif de MS SQL Server.
> > Si quelqu'un a la réponse je le remercie d'avance. > > Merci. > > David C. >
Ce n'est d'ailleurs pas du tout une bonne méthode que de penser que la copie de fichier de la base peut servir de solution de réplication. Vous avez toutes les chances que vos fichiers ne servent à rien car il peuvent s'avérer inexploitable...
En effet microsoft ne garantie pas la consistance des bases de données en dehors des procédures sp_detach/sp_attach, du BACKUP / RESTORE ou encore des mécanismes de réplication interne à SQL Server parmi lesquels le log shipping relativement facile à implementer constituerait la meilleure alternative à votre problématique.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
jld
bonjour,
J'expérimente actuellement une config semblable à la votre.
Je m'interrogeais également sur la non evolution des attributs de fichiers au niveau des bases SQL server et voila donc la réponse !
J'ai par contre un problème que je n'arrive pas à résoudre. Je teste la validité de la réplication en créant par exemple des tables sur le serveur primaire, en arrêtant ensuite la réplication double take sur celui-ci et en activant ensuite les services sur le serveur de secours. Une fois sur deux (environ) j'obtiens une base marquée suspecte par sql server.
Je réplique avec un contrôle de checksum l'intégralité du répertoire data mais pas le répertoire log.
Avez vous déjà rencontré ce type de problème ? je passe surement à côté d'un truc tout bête.
Merci d'avance
Jean-luc derrien
bonjour,
J'expérimente actuellement une config semblable à la votre.
Je m'interrogeais également sur la non evolution des attributs de
fichiers au niveau des bases SQL server et voila donc la réponse !
J'ai par contre un problème que je n'arrive pas à résoudre. Je teste
la validité de la réplication en créant par exemple des tables sur
le serveur primaire, en arrêtant ensuite la réplication double take
sur celui-ci et en activant ensuite les services sur le serveur de
secours. Une fois sur deux (environ) j'obtiens une base marquée
suspecte par sql server.
Je réplique avec un contrôle de checksum l'intégralité du
répertoire data mais pas le répertoire log.
Avez vous déjà rencontré ce type de problème ? je passe surement à
côté d'un truc tout bête.
J'expérimente actuellement une config semblable à la votre.
Je m'interrogeais également sur la non evolution des attributs de fichiers au niveau des bases SQL server et voila donc la réponse !
J'ai par contre un problème que je n'arrive pas à résoudre. Je teste la validité de la réplication en créant par exemple des tables sur le serveur primaire, en arrêtant ensuite la réplication double take sur celui-ci et en activant ensuite les services sur le serveur de secours. Une fois sur deux (environ) j'obtiens une base marquée suspecte par sql server.
Je réplique avec un contrôle de checksum l'intégralité du répertoire data mais pas le répertoire log.
Avez vous déjà rencontré ce type de problème ? je passe surement à côté d'un truc tout bête.
