Discussion :

[Greos]

Bonjour,

J' essaye de faire une requête qui me permettrait de savoir qu'elles sont les databases qui ont subit une modification. (insert - update - delete dans l'une des tables de la database)

j'utilise la requete suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
select name
 from sys.dm_db_index_usage_stats right outer join sys.databases 
on sys.dm_db_index_usage_stats.[database_id] = sys.databases.[database_id]
 where last_user_update is not null 
and name not in('master','model','msdb','tempdb') 
group by name

Malheuresement cette requête ne me remonte pas toutes les databases qui ont eu des modifications et je ne comprends pas pourquoi.

connaissez vous un autre moyen pour montrer les bases de données qui ont subit une modification ?

Merci d'avance.

[Ptit_Dje]

Bonjour,

Que voulez vous faire a terme de cette indication ?
Souhaitez vous savoir qui a fait ces modifications et quand ?
Quelle version de SQL Server utilisez vous ?

[SQLpro]

Ces données ne sont ni synchrones ni absolues. C'est pourquoi il peut y avoir des écarts important entre ce qui y figure et la réalité. Le but de ces données système est de fournir une indication, une tendance et non l'absolue vérités.
De ce fait vous utilisez à contre emploi une fonctionnalité !
En particulier ces tables sont vidées lors de l'arrêt d'une base ou du serveur.

Quel est votre but ? Car il existe de nombreux autres outils pour satisfaire vos besoins.

A +

[Greos]

Merci pour cette réponse (rapide en plus)

Que voulez vous faire a terme de cette indication ?

Le but est faire une réplication "sauvage". en gros le soir j ai une routine qui regarde si la base a eu une modification. si c est le cas la routine détache les base en questions et elle fait une copie sur un autre serveur et après elle rattache le tout.

Souhaitez vous savoir qui a fait ces modifications et quand ?

Non.

Quelle version de SQL Server utilisez vous ?

j utilise sqlserver 2005

[Greos]

Merci

Ces données ne sont ni synchrones ni absolues. C'est pourquoi il peut y avoir des écarts important entre ce qui y figure et la réalité. Le but de ces données système est de fournir une indication, une tendance et non l'absolue vérités.
De ce fait vous utilisez à contre emploi une fonctionnalité !
En particulier ces tables sont vidées lors de l'arrêt d'une base ou du serveur.

Quel est votre but ? Car il existe de nombreux autres outils pour satisfaire vos besoins.

A +

Le but est de faire une réplication en quelque sorte. (voir message au dessus apres votre réponse :p)

si vous avez un autre moyen je suis preneur.

[SQLpro]

ça n'est donc pas du tout sur cela qu'il faut compter !

Il existe 4 mécanismes différents pour faire de la réplication intégrée :

• snapshot,
• transactionnelle,
• peer to peer,
• fusion...

Et vous pouvez en sus utiliser au moins 3 autres mécanisme de suivi :

• triggers
• CDC (change data capture) / change tracking
• service broker

A partir duquel vous pouvez implémenter votre propre mécanisme de réplication
A +

[Ptit_Dje]

Un backup/restore des bases de donnees en question, peu importe si elles ont subie une modification serait elle une operation trop couteuse ?

A quel usage vont servir les bases de donnees cible ?

Les propositions de SQLpro sont d'autres solutions, plus complexes cependant a mettre en place et a gerer qu'un backup/restore.

[Greos]

ça n'est donc pas du tout sur cela qu'il faut compter !

Il existe 4 mécanismes différents pour faire de la réplication intégrée :

• snapshot,
• transactionnelle,
• peer to peer,
• fusion...

Et vous pouvez en sus utiliser au moins 3 autres mécanisme de suivi :

• triggers
• CDC (change data capture) / change tracking
• service broker

A partir duquel vous pouvez implémenter votre propre mécanisme de réplication
A +

Merci pour votre réponse je vais me renseigner sur ces différents outils.

[Greos]

Un backup/restore des bases de donnees en question, peu importe si elles ont subie une modification serait elle une operation trop couteuse ?

A quel usage vont servir les bases de donnees cible ?

Les propositions de SQLpro sont d'autres solutions, plus complexes cependant a mettre en place et a gerer qu'un backup/restore.

En fait je copie les donnée d'un serveur x vers un serveur y. Entre les deux serveurs il y a une connexion très lente.
De ce fait je cherche à limiter l'utilisation de la bande passante en ne copiant que les bases qui ont eu une modification.

d où mon intérêt de savoir qu'elle base a été modifiée.

De ce fait en utilisant des backup/restore je ne supprimerai pas mon problème de bande passante.

Je vais surement créer une nouvelle table et utiliser des trigger qui me permettront de savoir qu'elles bases ont subies des modifications.

Merci pour vos réponses

[SQLpro]

Le mieux dans ce cas est d'utiliser une réplication transactionnelle au fil de l'eau.

A +

[Greos]

Le mieux dans ce cas est d'utiliser une réplication transactionnelle au fil de l'eau.

A +

Il parait que lorsque l'on utilise une réplication on ne peut plus toucher au table ou difficilement. (rajouter des colonnes par exemple)

C est pourquoi je n'ai pas mis en place ce principe.

[SQLpro]

Commencez par vous former au lieu de reprendre des bobards ou des on dits.
Sachez qu'on peut même répliquer le schéma d'une base par la réplication. Autrement dit synchroniser les évolutions d'une base par rapport à une autre !

Il est vrai que la formation aux SGBDR et en particulier à SQL Server nécessite plusieurs dizaines de jours de cours, ce qu'hélas peu de gens font et répandent quantité de stupidité discréditant ainsi le produit !

A +

[Greos]

Commencez par vous former au lieu de reprendre des bobards ou des on dits.
Sachez qu'on peut même répliquer le schéma d'une base par la réplication. Autrement dit synchroniser les évolutions d'une base par rapport à une autre !

Il est vrai que la formation aux SGBDR et en particulier à SQL Server nécessite plusieurs dizaines de jours de cours, ce qu'hélas peu de gens font et répandent quantité de stupidité discréditant ainsi le produit !

A +

Ok merci