Discussion :

[jeeps64]

Bonjour

Je suis entrain d'étudier une solution pour déclencher automatiquement sur seuil d'alerte un dump tran.
Le système mis en place en général s’appuie sur le système d'alert (1 alert par base de données / Compteur ‘Percent Log Used’) et un job / base lançant le dump tran.
Or quand on a des centaines de bases sur un même serveur ça fait des centaines de jobs et d'alertes.

Est-ce que quelqu'un a une autre solution ?
La solution du job cyclique étant déjà en place chez nous mais considéré comme une solution secondaire

Merci de votre aide
Jeeps64

[SQLpro]

Avant tout une sauvegarde n'est pas un dump.... Lisez ceci http://blog.developpez.com/sqlpro/p7...-et-log-ne-so/
Je pense que vous avez deux problèmes :

• un trop grand nombre de base sur un même serveur
• un mauvais paramétrage du mode de journalisation

1) il n'est pas conseillé d'avoir des centaines de bases de données sur un même serveur... Quel est le but de ces centaines de base ???
2) si vous ne gérez pas correctement la sauvegarde du journal de transaction autant passer au mode de journalisation SIMPLE. Vous n'aurez plus de sauvegardes ni d'alertes à créer !

A +

[dbaffaleuf]

C'est l'analogie avec Sybase (dump database / dump tran).

Il faudrait n connexions or 1 job ouvre 1 connexion. Tu peux le faire avec un package SSIS et N 'Execute SQL Tasks' en entrée, en boucle tant qu'il reste des bases à traiter, et programmer dans un job. Il ne faut pas en, lancer trop en même temps. Idéalement, un backup crée deux threads donc si tu as 16 CPU, disons que tu peux lancer 8 backups en //.

Sinon il faut faire un petit programme qui fasse la même chose avec des threads C# par exemple.

HTH A+

[kagemaru]

hello

allez, mes 2 euros : un script powershell qui lance les dump tran (pardon les backup log) en parallèle ...

Quel est le but de ces centaines de base ???

oui c'est vrai ça, pourquoi autant de bases ? Peux-tu donner un peu de contexte ?

merci

[SQLpro]

...un backup crée deux threads donc si tu as 16 CPU, disons que tu peux lancer 8 backups en //.

Et donc plus aucun CPU de libre pour le service des données !!!!!!

A +

[dbaffaleuf]

Et donc plus aucun CPU de libre pour le service des données !!!!!!

A +

A chaque fin de backup log correspond la fin d'un batch donc yield du worker, d'autres demandes peuvent être traitées par SQLOS sans problème. Le but c'est quand même d'utiliser la CPU au maximum, ce n'est pas comme s'il s'agissait de deux process distincts. Disons que 8 est une valeur maximale au delà de laquelle il y aura des changements de contexte.

[mikedavem]

Si toutes les CPU sont occupés par les threads associées aux backups les données pourront être traités de toute manière. Lorsqu'un traitement devra être traité par un processeur il y aura probablement suspension d'une tâche associé aux backups pendant un laps de temps. On verra par ce fait le compteur de type d'attente SOS_SCHEDULER_YIELD augmenté.

A voir maintenant si les tâches de backups sont longues ou pas ...

++