Avis sur config pour SSAS

**janlouk** · 14/12/2017, 12h48

Bonjour à tous,

Je voudrais avoir une confirmation svp.

Actuellement, sur le serveur PROD01 il y a une DB très sollicitée. A cela, il y a un serveur qui va chercher avec des jobs ETL (SSIS) les infos pour alimenter un autre serveur où SSAS (très sollicité aussi) est installé pour le reporting.

La demande est de soulager le serveur PROD01, et d'ajouter un replica. SSAS ira attaquer ce replica et plus la prod directement.

Il faut que le replica soit à jour toutes les 30 minutes maximum.

Je ne vois que 3 possibilités et merci de me confirmer svp :

1. Log shipping : mais le problème c'est que la DB ne sera pas accessible pendant le restore et ce sera régulier
2. Mirroring : je sais qu'on peut mettre la DB en read only, mais est-ce une bonne solution?
3. Always On, pour moi c'était la meilleur solution, mais je viens d'apprendre que c'était Standard Edition, donc la DB ne sera pas en Read, donc ça n'ira pas

Pour faire des économies, ils envisagent de mettre la seconde DB sur le même serveur que SSAS. Très mauvaise idée si cette DB n'est utilisée que par SSAS et les jobs d'SSIS?
Si cette solution est choisie, ais-je des restrictions pour installer AO? Ou je ne pourrai utiliser que le mirroring?

Merci,
Jean-Luc

**SQLpro** · 14/12/2017, 17h11

Envoyé par janlouk

1. Log shipping : mais le problème c'est que la DB ne sera pas accessible pendant le restore et ce sera régulier

Oui

2. Mirroring : je sais qu'on peut mettre la DB en read only, mais est-ce une bonne solution?

Non, le miroir n'est pas lisible

3. Always On, pour moi c'était la meilleur solution, mais je viens d'apprendre que c'était Standard Edition, donc la DB ne sera pas en Read, donc ça n'ira pas

Pour faire des économies, ils envisagent de mettre la seconde DB sur le même serveur que SSAS. Très mauvaise idée si cette DB n'est utilisée que par SSAS et les jobs d'SSIS?
Si cette solution est choisie, ais-je des restrictions pour installer AO? Ou je ne pourrai utiliser que le mirroring?

Merci,
Jean-Luc

Autre solution une réplication transactionnelle.

A +

**janlouk** · 14/12/2017, 23h11

Donc la réplication transactionnelle va me permettre de faire la même chose que le log shipping mais en permettant à la DB d'être tout le temps "online" et read only?

**julien94320** · 15/12/2017, 09h30

Autre solution changer de version de SQL Server et passer vers une version Entreprise pour avoir le Always on ...

Combien va vous coûter le temps de réaliser une réplication transactionnel ?

Combien va vous coûter de temps de mettre en place une solution Always On et un upgrade de version ? Combien coûte l'upgrade de version ?

Sur quelle version êtes vous ?

**SQLpro** · 15/12/2017, 10h19

Envoyé par janlouk

Donc la réplication transactionnelle va me permettre de faire la même chose que le log shipping mais en permettant à la DB d'être tout le temps "online" et read only?

Oui.

Comme le dit julien, c'est pas gagné. La réplication transactionnelle pompe beaucoup de ressources et il faut répliquer aussi le DDL.
S'il y a beaucoup de charge transactionnelle sur la base de départ, alors il va falloir un serveur avec BEAUCOUP de ressources...
Il n'est pas sûr que le surcoût d'un tel serveur et le maintient de la solution au fil du temps soit économique face à AlwaysOn en mode Enterprise !

A +

**janlouk** · 15/12/2017, 10h29

Envoyé par julien94320

Combien va vous coûter de temps de mettre en place une solution Always On et un upgrade de version ? Combien coûte l'upgrade de version ?

Je ne connais pas le coût des licences, je vais me renseigner

Sur quelle version êtes vous ?

Sorry, oublié de le mettre dans le titre: SQL 2016

Je vais voir aussi sur les problématiques évoqués par Frédéric pour l'obligation d'augmenter la puissance du serveur qui devra supporter la réplication, soit PROD01.

Donc si je résume bien avec vos commentaires :

Réplication : coûteuse en terme de ressources, et donc des frais supplémentaire
AO : Je dois passer à la version Enterprise
Log shipping : Solution la moins coûteuse, mais la DB ne sera pas accessible pendant le restore...

**SQLpro** · 15/12/2017, 12h57

Envoyé par janlouk

Log shipping : Solution la moins coûteuse, mais la DB ne sera pas accessible pendant le restore...

Et pour cette dernière, deux solutions :

1) attendre que les derniers utilisateurs aient terminés leurs requêtes avant de restaurer le journal suivant (ce qui peut être parfois lent, chaque utilisateur pouvant lancer une requête avant qu'un précédent n'ait terminé);
2) ou bien forcer la restauration du journal et donc interrompre les requêtes des utilisateurs.

Je sais que cette solution n'est pas viable, s'il y a beaucoup d'utilisateurs et si l'on veut se rapprocher du temps réel.

Pour information, la version Enterprise c'est juste 5 fois plus cher, et si AlwaysOn en réplicas READABLE alors il faut en sus la SA (Software Assurance) soit 7,5 fois plus cher !

A +

**janlouk** · 15/12/2017, 13h10

Envoyé par SQLpro

Pour information, la version Enterprise c'est juste 5 fois plus cher, et si AlwaysOn en réplicas READABLE alors il faut en sus la SA (Software Assurance) soit 7,5 fois plus cher !A +

Oui, mais tout ça, par an vu qu'il y a l'obligation de passer par la SA et que c'est une formule d'abonnement si je ne me trompe pas?