et logfile growth

Version imprimable

23/03/2015, 11h02
AlternantOracle

Always-on maintenance/backup/et logfile growth

Bonjour,

Je suis en train de mettre en place un SQL server always-on pour un client et voici la configuration:
Un primaire et un secondaire en lecture en mode synchrone avec backup préféré sur le secondaire.

Je me pose les questions suivantes:

Backups:
- Quelle stratégie de backup mettre en place sur le secondaire ?

Maintenance plan:
- mettre en place les rebuilds/reorganize sur le primaire affecte aussi le secondaire et vice versa (je penses que je rêve pour le vice versa :p) ?
- Faire mes DBCC CHECKDB sur la secondaire est une bonne politique afin de détecter la corruption ? (malgrès le système de récupération de blocs always-on)

logfile growth:
- Comment se gère le processus de grossissement/réduction de la taille des fichiers de transaction log (sur les 2 noeuds)?
- J'ai lancé un gros batch sur la primaire et le log ne se réduit pas dans le temps malgrès les plans de maintenance backups etc. Pourtant ce n'est pas en production actuellement et personne ne se connecte.

Merci d'avance,
Pour votre retour d'expérience.

Cordialement.
23/03/2015, 11h22
AlternantOracle

un petit up concernant le transactionlog.

Je peux voir ca:
SELECT [log_reuse_wait_desc]
FROM [master].[sys].[databases]

log_reuse_wait_desc
NOTHING
NOTHING
NOTHING
NOTHING
NOTHING
NOTHING
ACTIVE_TRANSACTION
LOG_BACKUP
NOTHING

J'ai beau faire autant de backup que log que je peux ca ne change strictement rien.
23/03/2015, 11h28
mikedavem

Citation:

- Quelle stratégie de backup mettre en place sur le secondaire ?

Ta stratégie n'est pas différente d'une instance standalone et dépend uniquement de ton business. Il faut traduire ensuite ton besoin en planification de sauvegarde vers AlwaysOn.
Sur le secondaire il faut cependant faire avec les limitations:
- Backup full uniquement en copy only (ce qui implique aussi qu'une stratégie à base de backup différentiel sera impossible)
- backup diff non supporté
- backup log possible

Citation:

Maintenance plan:
- mettre en place les rebuilds/reorganize sur le primaire affecte aussi le secondaire et vice versa (je penses que je rêve pour le vice versa :p) ?
- Faire mes DBCC CHECKDB sur la secondaire est une bonne politique afin de détecter la corruption ? (malgrès le système de récupération de blocs always-on)

Sur le secondaire ta base de données est en lecture seule donc aucune chance d'avoir un impact sur le secondaire :-)
Si tu fais tes backups sur le secondaire alors oui c'est une bonne pratique d'effectuer la vérification d'intégrité sur le primaire et sur le secondaire concerné par les sauvegardes

Citation:

logfile growth:
- Comment se gère le processus de grossissement/réduction de la taille des fichiers de transaction log (sur les 2 noeuds)?
- J'ai lancé un gros batch sur la primaire et le log ne se réduit pas dans le temps malgrès les plans de maintenance backups etc. Pourtant ce n'est pas en production actuellement et personne ne se connecte.

Pour cela il faut que tu regardes ce qui t'empêche de réduire ton journal (sys.databases et colonne log_reuse_wait_desc) mais vu de loin je pense que tu es bloqué par la synchronisation. A confirmer

++
23/03/2015, 11h29
mikedavem

Citation:

Envoyé par AlternantOracle

un petit up concernant le transactionlog.

Je peux voir ca:
SELECT [log_reuse_wait_desc]
FROM [master].[sys].[databases]

log_reuse_wait_desc
NOTHING
NOTHING
NOTHING
NOTHING
NOTHING
NOTHING
ACTIVE_TRANSACTION
LOG_BACKUP
NOTHING

J'ai beau faire autant de backup que log que je peux ca ne change strictement rien.

ok et que donne un

Code:

DBCC SQLPERF('logspace')

++
23/03/2015, 14h17
AlternantOracle

Hello Mike,

Merci pour tes retours que je viens de voir.

Du coup je suis arrivé à réduire le journal de transaction à coups de backups log + checkpoint en utilisant la vue log_reuse.

Merci pour tes réponses :).

Cordialement.
27/04/2016, 08h35
AlternantOracle

Citation:

Envoyé par mikedavem

Ta stratégie n'est pas différente d'une instance standalone et dépend uniquement de ton business. Il faut traduire ensuite ton besoin en planification de sauvegarde vers AlwaysOn.
Sur le secondaire il faut cependant faire avec les limitations:
- Backup full uniquement en copy only (ce qui implique aussi qu'une stratégie à base de backup différentiel sera impossible)
- backup diff non supporté
- backup log possible

Hello Mikedavem,

Pour information si tu fais aucun backup sur le primaire ça va te faire grossir indéfiniment la BDD. J'ai eu confirmation du support.

Citation:

BACKUP DATABASE supports only copy-only full backups of databases, files, or filegroups when it is executed on secondary replicas. Note that copy-only backups do not impact the log chain or clear the differential bitmap.
27/04/2016, 10h55
SQLpro

Citation:

Envoyé par AlternantOracle

Maintenance plan:
- mettre en place les rebuilds/reorganize sur le primaire affecte aussi le secondaire et vice versa (je penses que je rêve pour le vice versa :p) ?

Un plan de maintenance qui modifie les données ou index ne peut être réalisé que sur le primaire. En revanche DBCC CHECK... peut être fait sur le secondaire.

Citation:

- Faire mes DBCC CHECKDB sur la secondaire est une bonne politique afin de détecter la corruption ? (malgrès le système de récupération de blocs always-on)

Ne confondez pas bloc et page. Nous ne sommes pas sous oracle.... Une page SQL Server est toujours de 8 Ko et organisées dans une extensions qui est un bloc de 8 pages contiguës sur le disque, soit 64 Ko

Citation:

logfile growth:
- Comment se gère le processus de grossissement/réduction de la taille des fichiers de transaction log (sur les 2 noeuds)?

Contrairement à Oracle, SQL Server transactionne, y compris le DDL. Un agrandissement de fichier est juste une commande SQL interne journalisée et à ce titre répercutée dans les processus de mirroring sur lequel se base AlwaysOn (lecture des binaires du journal de transaction). tout et

Citation:

- J'ai lancé un gros batch sur la primaire et le log ne se réduit pas dans le temps malgrès les plans de maintenance backups etc. Pourtant ce n'est pas en production actuellement et personne ne se connecte.

Le JT ne se réduit jamais naturellement. Il ne fait que grossir. Pour le réduire il faut effectivement faire appel à DBCC SHRINK... qui doit rester une opération tout à fait exceptionnelle.

Citation:

Merci d'avance,
Pour votre retour d'expérience.

Cordialement.

PS : j'ai monté un cours SQL Server admin de 3 jours pour les DBA Oracle à Orsys si cela vous intéresse :
http://www.orsys.fr/formation-admini...sql-server.asp

A +
11/05/2016, 00h15
mikedavem

@AlternantOracle Désolé de revenir sur ce thread tardivement (et clôturé)

Citation:

Hello Mikedavem,

Pour information si tu fais aucun backup sur le primaire ça va te faire grossir indéfiniment la BDD. J'ai eu confirmation du support.

Si on parle bien de la même chose, à savoir des journaux de transaction qui grossissent indéfiniment avec une stratégie de sauvegardes de journal depuis le(s) secondaires qui ne videraient pas le journal, alors j'aurais quelques exemples clients ou démos simples qui prouveraient le contraire. La documentation Microsoft est également clair sur le sujet:

Additionally, the log backup chain is supported across all replicas regardless of where the log backup is taken (primary or secondary replicas) or the mode of the replication (asynchronous or synchronous).

Mais bon parle-t-on bien de la même chose ici? Si tu as un peu de temps pour répondre ca sera volontiers que je lirais ta réponse :-)

++
23/06/2016, 11h57
AlternantOracle

Bonjour,

Merci a vous 2 pour les réponses (les choses ont beaucoup évoluées depuis mon tout premier post ;) ).
Ici bien entendu que le backup secondaire préserve la chaine LSN mais ce que je voulais dire c'est qu'en aucun cas il truncate le transactionlog.

Du coup on se retrouve avec des BDD qui grossissent sans faire de truncate de mon point de vue.
Je n'ai pas pris le temps de faire des tests afin de vérifier le comportement.

ps: j'utilise les scripts OLA pour faire mes backups (peut être que ça a une mauvaise influence sur mes résultats)
24/06/2016, 07h35
mikedavem

Citation:

Ici bien entendu que le backup secondaire préserve la chaine LSN mais ce que je voulais dire c'est qu'en aucun cas il truncate le transactionlog.

On est en ligne avec cela ;)

Citation:

Du coup on se retrouve avec des BDD qui grossissent sans faire de truncate de mon point de vue.

La nous ne sommes plus en phase :D Les backups de journal depuis les secondaires vont initier un truncate également sur le primaire. En réalité les réplicas AlwaysOn fonctionnent par message / tâche et lorsqu'un backup est correctement effectué depuis le secondaire, un message est envoyé au primaire pour initier un truncate du journal.

Je viens de refaire un test sur un des mes environnements et cela fonctionne comme prévu. Le message qui est visiblement utilisé pour synchroniser le truncate des journaux est NewLogReady (en mettant une petite trace XE)

Citation:

ps: j'utilise les scripts OLA pour faire mes backups (peut être que ça a une mauvaise influence sur mes résultats)

J'ai quelques clients qui l'utilisent également avec des infrastructures AlwaysOn et backup depuis les secondaires et nous n'avons pas eu ce souci à ce jour. (ce qui ne veut pas dire qu'il n'existe pas de cas où cela pourrait arriver et que nous n'avons pas encore rencontré ;) )
A froid, je ne vois qu'un cas où cela pourrait arriver avec un backup log with copy_only mais ce type de backup n'est pas autorisé depuis un secondaire.

Si tu as plus de précisions sur ton contexte et que tu as le temps je suis preneur ..

++
24/06/2016, 08h52
AlternantOracle

Hello Mike,

Merci pour ton temps et tes réponses :).
Du coup je vais aller reproduire cela avec des traces extended events.

Tu mets quels filtres pour avoir ces résultats ? Désolé d'abuser :)
Sur ce je vais aller lire ta présentation extended events.

Cordialement,
Jonathan.