Erreur de groupe de disponibilité AlwaysOn SQL Server: 1408 La jointure de base de données sur le réplica secondaire entraînait une erreur

J’ai été en train de configurer un environnement SQL Server AlwaysOn à deux nœuds. Lors de la configuration, nous avons reçu  »
Error: 1408 Joining database on secondary replica resulted in an error.  » Comment cette erreur s’est-elle produite et comment la résolvons-nous?

Vous pouvez voir ici que SQL Server AlwaysOn a été configuré avec succès sur le réplica secondaire xxxx, alors qu’une erreur s’est produite pour le réplica secondaire xxxx. Nous allons maintenant vérifier les détails de l’erreur pour résoudre ce problème. Vous pouvez cliquer sur le lien « Erreur » pour obtenir les détails de l’erreur, comme indiqué dans la capture d’écran ci-dessous.

vous verrez que la base de données posant problème comporte un point d’exclamation. Faites un clic droit sur cette base de données et cliquez sur «Rejoindre un groupe de disponibilité»

Maintenant, si vous lancez le rapport de tableau de bord SQL Server AlwaysOn, vous pouvez voir l’état actuel de la configuration AlwaysOn, comme indiqué dans la capture d’écran ci-dessous.

Les détails de l’erreur indiquent que « la copie distante de la base de données » DRTest « n’est pas récupérée suffisamment pour permettre la mise en miroir de la base de données ou pour la joindre au groupe de disponibilité. Vous devez appliquer les enregistrements de journal manquants à la base de données distante en restaurant le fichier en cours. enregistrer les sauvegardes de la base de données principale / principale. (Microsoft SQL Server, Erreur: 1408) « . Cela signifie que les bases de données source et cible ne sont pas synchronisées. Nous allons résoudre ce problème dans cette astuce. Cliquez sur le bouton OK pour fermer cette fenêtre.

Alter database production SET HADR AVAILABILITY GROUP = AVGProduction;

Msg 1478, Level 16, State 101, Line 1
The mirror database, « XXXXX », has insufficient transaction log data to preserve the log backup chain of the principal database. This may happen if a log backup from the principal database has not been taken or has not been restored on the mirror database.

Vous devez restaurer la sauvegarde du journal qui a été prise à partir de la base de données primaire vers la base de données secondaire et réessayer. Si vous ne trouvez pas la sauvegarde du journal ou si vous avez effectué la sauvegarde avec une autre application de sauvegarde, effectuez une sauvegarde différentielle, puis effectuez une sauvegarde du journal à partir de la base de données principale et restaurez ces sauvegardes dans la base de données secondaire en mode Norecovery

 cliquez avec le bouton droit de la souris sur la base de données secondaire dans l’onglet Bases de données de disponibilité, puis cliquez sur « Join To Avaibility Groupe »

. Au bout d’un moment, vous constaterez que l’état de la base de données secondaire est à nouveau synchronisé et que le problème est corrigé.

on passe maintenant à la réplique principale xxxxxx et lancez le rapport de tableau de bord SQL Server AlwaysOn pour cette configuration. Le rapport de tableau de bord du groupe de disponibilité « xxxxx » apparaît dans le volet de droite. L’état du groupe de disponibilité est maintenant sain et toutes les valeurs d’état sont vertes. Vous pouvez valider la configuration de la réplique secondaire xxxxx ainsi que celle illustrée ci-dessous.

lancer un vacuum full pour récupérer d’espace disque

Un détail à noter sur  l’autovacuum   c’est qu’il ne restitue pas l’espace qu’il libère dans le système d’exploitation. Au lieu de cela, il ne marque que l’espace comme libre, de sorte qu’il peut être utilisé plus tard de nouvelles lignes. Cela signifie que si vous avez un volume de 100 Go et que vous en supprimez la moitié, il occupera tout de même 100 Go, même si vous exécutez  VACUUM dessus. Pour contourner ce problème, Postgres a une commande  VACUUM FULL .

VACUUM FULL  prend une table existante et crée une nouvelle copie de la table. Cela permettra au système d’exploitation de récupérer tout l’espace libre utilisé auparavant par les lignes, mais il présente quelques inconvénients. L’implémentation actuelle de  VACUUM FULL  verrouille complètement la table en cours d’aspiration. Cela signifie que vous ne pourrez pas exécuter de requêtes ni insérer de données dans la table tant que VACUUM FULL n’est pas  terminé. En général, si vous voulez récupérer tout l’espace vide d’une table, au lieu d’utiliser  VACUUM FULL , vous devriez regarder pg_repack . L’extension pg_repack est une extension Postgres qui fournit une commande équivalente à  VACUUM FULL cela vous permet toujours d’exécuter des requêtes sur la table en cours de compactage

create table Test_vacumm (a int , b varchar(50), c varchar(80));

 
 insert into test_vacumm (a,b,c) select 1, md5('abdallah'::varchar), md5('abdallah'::varchar) from generate_series ( 1, 60000000 ) ;
INSERT 0 10000000

en lançant une requête de delete massive

delete from  test_vacumm;

DELETE 60000000

j’utilise cette petit requête

delete from  test_vacumm;

Pour récupérer les taille des différent table dans ma base de donnée

SELECT N.nspname || '.' || C.relname AS "relation",
    CASE WHEN reltype = 0
        THEN pg_size_pretty(pg_total_relation_size(C.oid)) || ' (index)'
        ELSE pg_size_pretty(pg_total_relation_size(C.oid)) || ' (' ||  pg_size_pretty(pg_relation_size(C.oid)) || ' data)'
    END AS "size (data)",
    COALESCE(T.tablespace, I.tablespace, '') AS "tablespace"
FROM pg_class C
LEFT JOIN pg_namespace N ON  (N.oid = C.relnamespace)
LEFT JOIN pg_tables T ON (T.tablename = C.relname)
LEFT JOIN pg_indexes I ON (I.indexname = C.relname)
LEFT JOIN pg_tablespace TS ON TS.spcname = T.tablespace
LEFT JOIN pg_tablespace XS ON XS.spcname = I.tablespace
WHERE nspname NOT IN ('pg_catalog','pg_toast','information_schema')
ORDER BY pg_total_relation_size(C.oid) DESC;

alors j’obtiens cette résultat

En lançant un vacuum FULL

VACUUM FULL verbose test_vacumm;

INFO: exécution du VACUUM sur « public.test_vacumm »
INFO: « test_vacumm » : 46347450 versions de ligne supprimables, 0 non supprimables
parmi 740741 pages
DÉTAIL : 0 versions de lignes ne peuvent pas encore être supprimées.
CPU 15.82s/13.03u sec elapsed 53.02 sec.

N’oubliez pas que VACUUM FULL nécessite un verrou exclusif sur la table afin que, pendant cette opération, votre table ne soit pas accessible.

aussi vous avez évidemment besoin d’un espace de stockage supplémentaire. il doit être au moins deux fois plus grand que la taille du table en question,. Si vous avez de la chance pouvez ajouter dynamiquement un disque à la machine

AlwaysOn Le réplica secondaire est à l’état » resolving state » après le basculement

bonjour

J’ai récemment installé un simple cluster de basculement à 2 nœuds qui sera utilisé pour le groupe de disponibilité AlwaysOn. Après l’installation, j’ai proposé au client d’effectuer des tests de basculement, non seulement pour connaître le comportement du cluster de basculement Windows, mais également pour voir comment les applications réagiraient en cas de basculement. 
Lorsque j’ai désactivé la carte réseau sur le nœud hébergeant le groupe de clusters, le basculement a bien fonctionné comme prévu

J’ai réactivé la carte réseau et effectué le même test sur l’autre nœud (qui hébergeait maintenant le groupe de clusters). À ma grande surprise, il n’y a pas eu de basculement, mais le nom du cluster et l’adresse IP ont simplement été déconnectés

Cependant J’ai essayer 3  fois de basculé le secondaire il reste Toujours dans un état de « Résolution ».

J’ai vérifié les événements du cluster et constaté l’erreur suivante: « Le rôle de cluster ‘Groupe de cluster’ a dépassé son seuil de basculement»

Message D’erreur :
Based on the failure policies for the resource and role, the cluster service may try to bring the resource online on this node or move the group to another node of the cluster and then restart it. Check the resource and group state using Failover Cluster Manager or the Get-ClusterResource Windows PowerShell cmdlet.

selon la configuration du cluster par défaut La limite maximale de basculement est définie sur 1 fois sur 6 heures.

Par défaut, l’unité de temps est de 6h et le nombre de fois est de n-1 (n étant le nombre de nœuds). Par exemple avec une architecture à 2 nœuds, vous pouvez basculer au plus 4 fois dans la même journée (24 heures) , à condition que ces quatre basculement aient lieu à plus de 6h d’intervalle

vous devez cliquer avec le bouton droit sur le nom du cluster et sélectionner les propriétés. Maintenant, si vous regardez de plus près, il existe un «lien» dans les premières fenêtres appelé «Gérer le groupe de ressources du cluster principal». 
Je n’ai pas remarqué ce lien car la plupart des liens ne servent qu’à ouvrir les fichiers d’aide…

Accédez à l’onglet Basculement, où vous trouverez le nombre maximal d’échecs dans la période spécifiée. Par défaut, il est défini sur 1 dans une période de 6 heures. Cela ne suffit pas lors des tests de cluster de basculement et vous indiquera le problème que j’ai rencontré qui a échoué / hors connexion. 
Remplacez-le par une valeur plus élevée, telle que 10 par exemple

Veuillez noter que j’ai utilisé ces configurations uniquement à des opération de test

N’oubliez pas de rétablir la valeur par défaut une fois vos tests terminés.

Comment effectuer une sauvegarde PostgreSQL de base à l’aide de l’utilitaire pg_basebackup

Bonjour Si vous utilisez l’envoi de journaux de transactions (
(or Point-In-Time-Recovery) ) pour protéger vos données, vous connaissez sûrement déjà pg_basebackup. L’idée derrière pg_basebackup est de permettre aux utilisateurs de créer une copie binaire des données, qui peut servir de base à la récupération ponctuelle

Afin de faire fonctionner cet outil pg_basebackup, nous devons d’abord définir certaines variables de configuration dans le fichier postgresql.conf qui se trouve généralement dans le répertoire de données

• archive_mode
• archive_command
• wal_level
• max_wal_sender

archive_mode = on

max_wal_senders = 2		# max number of walsender processes

archive_command = 'test! -f / var / lib / pgsql / pg_log_archive /% f && cp% p / var / lib / pgsql / pg_log_archive /% f 

wal_level = replica			# minimal, replica, or logical

Redémarrez le service PostgreSQL pour appliquer les modifications.

:~$ pg_ctlcluster 9.4 main restart

Pg_basebackup établit une connexion au protocole de réplication (exactement comme un client de réplication) sur le serveur PostgreSQL et crée une copie binaire des fichiers de données stockés dans le $PGDATA répertoire du serveur. La copie qu’il crée est cohérente – les fichiers correspondent exactement à l’état à la fin d’une transaction particulière

Créez un utilisateur avec le privilège de réplication car pg_basebackup a besoin du privilège de réplication pour créer une sauvegarde de base [il existe plusieurs façons de créer un utilisateur, je suis celui qui suit]:

su - postgres- postgres psql -c "CREATE ROLE base_backup_user REPLICATION LOGIN PASSWORD 'backupuser';"-c "CREATE ROLE base_backup_user REPLICATION LOGIN PASSWORD 'backup';"

Mettez à jour le fichier pg_hba.conf situé dans le répertoire de données postgres [/var/lib/pgsql/9.4/data] et ajoutez une règle pour activer cet utilisateur nouvellement créé sous la section de connexions de réplication de ce fichier, jusqu’à la fin du fichier:

                                                                                vi  /var/lib/pgsql/9.4/data/pg_hba.conf 

            host     replication     base_backup_user       127.0.0.1/32     trust             

Si vous craignez des transactions manquantes pendant la sauvegarde, vous pouvez demander à pg_basebackup d’extraire et d’inclure ces fichiers du journal des transactions (fichiers WAL) à l’aide des options -xou -X

Tar and Compressed Format
$ pg_basebackup -h localhost -p 5432 -U postgres -D /backupdir/latest_backup -Ft -z -Xs -P

 
Plain Format
$ pg_basebackup -h localhost -p 5432 -U postgres -D /backupdir/latest_backup -Fp -Xs -P

À ce stade, vous êtes prêt à effectuer une sauvegarde de base à l’aide de pg_basebackup.

Surveiller SQL Server Agent with Powershell

bonjour
Dans Cet article je vous présente du code PowerShell
le code il montre comment Surveiller l’agent SQL Server pour s’assurer qu’elle est en cours d’exécution sur des multi serveurs .
Il y a quelques mois, une situation intéressante s’est produite. SQLAgent s’est arrêté et il a fallu un certain temps avant de réaliser ce qui s’était passé. Heureusement, il ne s’agissait pas d’un problème critique sur ce serveur, mais cela aurait pu être un problème majeur sur d’autres serveurs de production. Cela m’a fait poser une question intéressante. comment surveillez-vous SQL Server, en particulier SQLAgent sur un Parc SQL alors c’est a travers Powershell
Commençons par résoudre le problème que je viens d’évoquer en définissant un fichier texte contenant les listes de serveurs à surveiller. Ouvrez simplement un éditeur de texte, tapez les adresses IP ou les noms de votre serveur, ou un mélange des deux, puis enregistrez le fichier dans votre répertoire local. Dans mon cas, j’utilise c: \servers.txt, par exemple:

$servers=get-content "c:\servers.txt"
$servers

Pour chaque objet renvoyé à partir de la variable $servers, nous allons le placer dans la variable $server, puis vérifier le serveur à la recherche d’instances d’agent SQL Server en statut Agent Stopped.
Dans Powershell, vous utilisez le caractère | pour indiquer que vous souhaitez Powershell transmette les valeurs de la commande de gauche à celle de droite. Voici ce que le script ci-dessus fait:
Nous demandons d’abord à Powershell d’obtenir les valeurs WMIobject pour tous les services win32 et nous passons le nom du serveur dans le paramètre –computername.
Ensuite, nous prenons les valeurs de l’appel get_wmiobject et on sélectionne uniquement le nom et les valeurs d’état renvoyées par la commande, car ce sont les seules sur lesquelles nous souhaitons travailler dans notre exemple.
Nous filtrons ces résultats de 2 manières. Premièrement, nous utilisons une recherche générique et l’opérateur –like sur les noms ($ _. Name) pour tout nom commençant par « SQLAgent » ou commençant par « SQL » et se terminant par « Agent » et qui a (-match ) un état « arrêté ».
Enfin, nous prenons nos résultats filtrés et demandons à Powershell de générer ces informations sous forme de chaîne. La dernière étape de la sortie sur une chaîne devient importante plus tard.
Maintenant, si nous nous arrêtions là, vous pourriez surveiller manuellement les serveurs de votre choix et voir quels services étaient arrêtés. Bien que cela soit modérément utile, il serait bien que cela puisse fonctionner sur un ou plusieurs serveurs distants et le démarrer automatiquement a travers start-service . Laissons cela en modifiant légèrement le code ci-dessus.

$servers=get-content "c:\servers.txt"

foreach($server in $servers)
{
$statut=get-wmiobject win32_service -computername $server |
  select name,state |
  where {$_.name -like "SQLAGENT*" -or $_.name -like "SQL*AGENT" `
   -and $_.state -match "Stopped"}
   $name=$statut.name
  }    

if ($statut.state -match "stopped")
{
start-service -Name  $name
}

 bonne surveillance

Crée et utilisée le Fichier .PGPASS

Bonjour a tous

Le  fichier .pgpass vous permettra d’utiliser des outils CLI tels que psql et pg_dump sans avoir à saisir manuellement un mot de passe. Vous pouvez utiliser les programmes à partir de scripts sans les exécuter en tant qu’utilisateur non protégé par mot de passe.

Tout d’abord, créez le fichier .pgpass

#nano /root/.pgpass 

Selon la documentation officielle,  le format du fichier est le suivant:

nom d'hôte : port : base de données : nom d'utilisateur : mot de passe

Le fichier prend en charge l’utilisation de balises # pour les commentaires et * pour faire correspondre les caractères génériques. Voici un exemple de la mienne:

*: *: *: postgres: postgres

Entrez les informations de votre base de données et enregistrez.

Ensuite, définissez les autorisations. S’ils ne sont pas 600, Postgres ignorera le fichier.

#chmod 600 /root/.pgpass

Maintenant, comment pouvons-nous utiliser postgres? Une analyse rapide de la page de manuel psql montre

psql -d postgres -U postgres -w
#pg_dump -U postgres -w -Fc

PostgreSQL: Comment désinstaller PostgreSQL 9.6 SOUS Ubuntu

bonjour
Dans ce post, je partage les étapes nécessaires pour supprimer ou désinstaller PostgreSQL 9.6 sous Ubuntu Comme il s’agit de mon serveur de test, j’ai tout simplement désinstallé le programme d’installation complet, puis à nouveau l’installé
Veuillez vérifier ci-dessous les commandes que j’ai appliquées pour désinstaller PostgreSQL

Commencez par vérifier les dossiers associés à Postgres

ps aux | grep postgres 

la Commande suivantes vous permet de supprimer POstgresql sous ubunto

sudo apt-get --purge remove postgresql-9.6   postgresql-client  postgresql-client-9.6 

 

rm -rf /etc/postgresql/
rm -rf /var/lib/postgresql/
rm -rf /var/log/postgresql/

Maintenant vérifier bien que PostgreSQL est désinstallé, vérifiez si PSQL est en cours d’exécution ou non

PSQL -U postgres 

The program 'psql' is currently not installed. You can install it by typing:
sudo apt install postgresql-client-common

Comment Activé la clé de licence SQL Server?

bonjour a tous

Ce tutoriel explique comment réaliser un upgrade SQL Server Evaluation Edition valable sur une période de 180j  vers une édition payante Entreprise

La procédure de mise à jour de la clé de produit SQL server est simple. En réalité, ces étapes sont identiques à celles requises pour mettre à niveau l’édition de SQL Server

Si SQL est déjà installé, vous pouvez également lancer le «Centre d’installation» en cliquant sur Démarrer-> Programmes -> Microsoft SQL Server 2017> Outils de configuration-> Centre d’installation SQL Server [(64 bits)]

donc Vous obtiendrez l’écran ci-dessous  Allez à « Maintenance » et cliquez sur « Edition Upgrade » comme indiqué ci-dessous

Renseigner après la clé de produit (product key) pour sélectionner l’édition achetée.

Vérifier le récapitulatif des opération à effectuer, ici l’action est une « Edition Update » vers l’édition « Entreprise » avec la liste des fonctionnalités et le nom de l’instance conservée

un écran récapitule les étapes de migration avec leur état

Maintenant si on vérifie on voit  qu’on arrive bien a activé la version Entreprise Edition

Le serveur SQL est maintenant sous licence Entreprise et il est bien Activé

Si vous voulez le faire en ligne de commande, vous pouvez lancer setup.exe avec les paramètres requis.

Setup.exe /q /ACTION=EditionUpgrade /INSTANCENAME=MSSQLSERVER /PID=” /IACCEPTSQLSERVERLICENSETERMS

bonne Activation

Synchroniser vos données a travers le composant SSIS Jointure de fusion

Bonjour

Auparavant, j’ai écrit un article sur la conception et la mise en œuvre d’un UPSERT LOOKUP qui concerne la mise à jour des enregistrements existants et l’insertion de nouveaux enregistrements. Aujourd’hui, je souhaite également étendre cela en ajoutant l’opération de suppression  Ainsi, la méthode utilisée dans cet article peut être utilisée pour trouver des enregistrements INSERTED / UPDATED / DELETED à partir de la table source et appliquer ces modifications à la table de destination.

Dans cet exemple, j’ai utilisé la transformation de jointure de fusion, le fractionnement conditionnel et la transformation de commande OLE DB pour implémenter la solution

Tout d’abord, nous appliquons une jointure externe complète sur la table source et de destination dans la ou les colonnes clés avec la transformation Fusion de jointure. Nous utilisons ensuite une division conditionnelle pour déterminer le type de modification (enregistrements supprimés, nouveaux ou existants). Les enregistrements existants nécessiteront un autre traitement pour savoir s’il y a eu des changements ou non? Nous utilisons un autre fois le fractionnement conditionnel pour comparer la valeur des colonnes équivalentes dans la source et la destination

Je montrerai donc comment synchroniser ces données entre serverA et serverB en utilisant une jointure de fusion dans SSIS

Voici à quoi ressemble mon package SSIS. Je vais discuter de chacune des étapes

J’ai deux sources OLE DB, une pour serverA (source) et l’autre pour serverB (destination). Voici comment ces connexions sont configurées

Lors de l’application d’une jointure par fusion, les données doivent être triées pour les deux entrées. J’applique donc une opération de tri des deux côtés

Maintenant Faites glisser le composant Jointure de fusion connecter Sur les deux sources OLE DB  Définissez la table source comme gauche et la table de destination comme entrée droite de cette transformation.

Allez dans l’éditeur du composant Jointure de fusiones , le colonne ID sera utilisé comme colonne de jointure (sélectionnée en fonction des propriétés de tri des composants précédents). Notez que si vous ne triez pas les colonnes d’entrée de la transformation de jointure de fusion, vous ne pouvez pas entrer dans l’éditeur de cette transformation et vous rencontrez l’erreur concernant le tri des entrées.

Sélectionnez toutes les colonnes des tables Source et Destination dans la transformation de jointure de fusion et renommez-les comme le montre l’image ci-dessous

À l’étape suivante, j’ai appliqué le composant Fractionnement conditionnel J’ai ajouté trois conditions différentes en fonction du résultat de la jointure externe complète. Ce sont les trois conditions:

1. UPDATE (correspondance avec ID): Si le ID existe à la fois sur la source et la destination, nous effectuons une mise à jour.
2. INSERT (id introuvable dans la destination): Si ID se trouve uniquement à gauche (source), nous devons insérer ces données dans la table de destination.
3. DELETE (ID est introuvable dans la source): Si ID n’est pas trouvé dans la table source, nous devons supprimer ces données de la table de destination                           

1 Insert !ISNULL(id) && ISNULL(id_NEW)
2 Delete ISNULL(id) && !ISNULL(id_NEW)
3 Update !ISNULL(id) && !ISNULL(id_NEW)

Nous avons donc maintenant trois flux de données pour effectuer une insertion, une mise à jour ou une suppression.

• Opération insert

Ajouter une destination OLE DB et connecter la sortie NEW RECORDS. Définissez la configuration de la table de destination et utilisez des colonnes avec le préfixe source dans le mappage de colonnes de la destination OLE DB. Ce composant de destination insérera de nouveaux enregistrements dans la table de destination

• Opération delete

Pour supprimer des données, j’ai une connexion de destination OLE DB et j’ai ajouté une commande sql comme suit à l’aide de l’éditeur avancé

delete from Produit_new
where id_NEW=?

• Opération Update

Ajouter de nouveau le composant  Fractionnement conditionnel   Nous utilisons ce composant pour rechercher uniquement les enregistrements qui ont changé dans l’une des valeurs. Nous comparons donc les colonnes source et destination équivalentes pour trouver des données non correspondantes.C’est l’expression utilisée pour trouver les données de correspondance dans la capture d’écran ci-dessous

Après avoir lancé la commande avec le paramètre «?», J’ai ensuite appliqué le mappage de colonne d’entrée avec les colonnes de destination de paramètres disponibles en fonction de la table de destination

Exécution du package

Après avoir configuré toutes les étapes ci-dessus, en changeant au hasard certaines des données, je lance alors le package et obtient les éléments suivants

Conclusion

la synchronisation a été bien passer entre la table source et la destination  en effectuant  des opérations d’insertion, de mise à jour et de suppression avec des données de la source vers la destination

Modifier le mode de déploiement SSAS du mode multidimensionnel au mode tabulaire sans réinstaller Analysis Services

Bonjour

Analysis Services peut être installé dans l’un des trois modes serveur suivants: Exploration multidimensionnelle et d’exploration de données (par défaut), Power Pivot pour SharePoint et Tabulaire. Le mode serveur d’une instance Analysis Services est déterminé lors de l’installation lorsque vous choisissez les options d’installation du serveur.
Comment vérifier le mode ?

Connectez-vous à l’instance dans SQL Server Management Studio et cliquez avec le bouton droit sur le nom de l’instance. Ensuite, sélectionnez Propriétés

Dans la capture d’écran ci-dessous, vous pouvez voir que le mode serveur est en mode multidimensionnel.

Pour modifier le mode de déploiement

• Sauvegarde des bases de données Analysis Services multidimensionnelles sur l’instance (le cas échéant)
• Détachez les bases de données Analysis Services multidimensionnelles de l’instance (le cas échéant). Ces bases de données ne seront pas utilisables en mode tabulaire
• Naviguez jusqu’au chemin « : \ Program Files \ Microsoft SQL Server \ MSAS11.MSSQLSERVER \ OLAP \ Config » et sauvegardez le fichier « msmdsrv.ini »
• Ouvrez le fichier « msmdsrv.ini » et remplacez la valeur de DeploymentMode par 2.
  0 – Multidimensional
  1 – SharePoint
  2 – Tabular

le fichier msmdsrv.ini est sur ce emplacement C:\Program Files\Microsoft SQL Server\MSAS12.SQLPROD\OLAP\Config

Ouvrez le fichier de configuration dans le Bloc-notes. Modifiez la propriété du mode de déploiement de 0 (multidimensionnelle) à 2 (tabulaire). Dans la capture d’écran ci-dessous, le mode de déploiement est défini sur 0 (mode multidimensionnel)

• Redémarrez les services SQL Server Analysis

Mode multidimensionnel SSAS – Avant modification

Mode tabulaire SSAS – Après modification