Discussion :

[DBA_OCP]

Bonsoir,

J'ai une configuration AlwaysOn avec deux bases dessus une en sychrone et la deuxième en asynchrone.

Je me demande si c'est possible de créer des index sur le serveur Always ON (la copie de ma base) uniquement ? Logiquement je pense que c'est non puisque c'est une réplication de la base principale mais je pose quand même la question...

Si j'utilise le serveur always on pour le reporting est ce que ça agit sur les performances de l'instance (principale et secondaire) ?

Merci d'avance pour vos réponses.

[Blacknounou]

Bonjour,

Je me demande si c'est possible de créer des index sur le serveur Always ON (la copie de ma base) uniquement ? Logiquement je pense que c'est non puisque c'est une réplication de la base principale mais je pose quand même la question...

La réponse est bien sûr NON, la base située sur un secondaire n'est pas accessible en écriture donc impossible de créer un index.

Si j'utilise le serveur always on pour le reporting est ce que ça agit sur les performances de l'instance (principale et secondaire) ?

Afin de diminuer la charge sur le serveur primaire , il est préférable de faire pointer un serveur de reporting vers le secondaire accessible en READ ONLY.

Cordialement,

[mikedavem]

Si j'utilise le serveur always on pour le reporting est ce que ça agit sur les performances de l'instance (principale et secondaire) ?

Oui c'est possible en effet et des 2 côtés.

Sur le secondaire, il se peut que la charge de Reporting ait un impact sur le redo thread qui permet de rejouer les blocs de journaux répliqués sur le secondaire. Tu peux même te retrouver dans une situation (dans le pire des cas) où ton acticité de Reporting met à genoux ton réplica secondaire et ne lui permet plus d'aborder la charge répliquée depuis ton primaire.
Sur le primaire, si une commande DDL passe (un alter index rebuild par exemple ou alter table) et qu'une requête de Reporting s'exécute au même moment et dure assez longtemps, le redo thread et les commandes qui suivent la commande DDL seront bloquées tant que la requête de Reporting n'est pas terminée.

Un impact également sur le stockage. si tu utilises ton réplica secondaire en lecture est l'ajout des 14 octets permettant de gérer le versionning et la concurrence d'accès (mode d'isolation SI).

A garder également en tête que déporter ton activité de Reporting sur un réplica en lecture seule a un coût car il faudra également licencier ce dernier.

A+

[SQLpro]

Sur le primaire, si une commande DDL passe (un alter index rebuild par exemple ou alter table) et qu'une requête de Reporting s'exécute au même moment et dure assez longtemps, le redo thread et les commandes qui suivent la commande DDL seront bloquées tant que la requête de Reporting n'est pas terminée.

Moindre si la commande est lancée WITH (ONLINE = ON).

A +