NT AUTHORITY\SYSTEM n'est plus sysadmin sur 2012

Dans nos tests de compatibilité sur 2012 (typiquement des migrations d'applications) nous nous sommes rendus compte que le login NT AUTHORITY\SYSTEM au niveau de l'instance n'est plus sysadmin sur SQL Server 2012 (c'était encore le cas en 2008 R2). Ce qui pose des problèmes quand, par exemple, vous avec un service Windows tournant avec le compte système local qui tente de piloter des bases de données pour votre application. On passe donc quelques temps à chercher pourquoi nous n'avons pas les droits sur Master afin de pouvoir créer une base par exemple.
La préconisation : ne pas faire tourner ces applications avec le compte système local et utiliser des comptes de domaine si possible. Dans tous les cas, on évite de mettre ce compte système local sysadmin des bases de l'instance SQL.

PowerShell, c'est la vie!

Commes mes fans se sont plaints  hier il y a peu du manque d'activité sur ce blog, voici un petit post pour les réconforter (si je n'ai rien publié depuis, c'est parce que je suis sur l'écriture d'un livre sur SSIS et que je n'ai pas grand chose de nouveau à dire : on se cherche des excuses comme on peut).

J'ai dû mettre en place aujourd'hui il y a peu la création automatique de partition sur SSAS. Ce n'est pas la première fois que je fais ça mais ici, la manière est bien différente car le contexte le requérait. D'habitude, la création de ces partitions s'inscrit dans un process global de mise à jour d'une partie du SID (ETL, DWH, etc...) : le tout est géré par un service Windows custom. Dans ce cas précis, l'AMO est idéal.

Bug de traduction dans AS lors de la modification des types des attributs

Nous venons juste de découvrir un bug marrant dans les traductions de SSAS. Enfin, marrant parce que de prime abord on ne voit pas d’où ça vient, mais qui fait tout de même perdre quelques heures de recherche.

Nous ne comprenions pas pourquoi, lors du procesing de notre dimension temps nous avions ce message d'erreur :

Errors in the back-end database access module. The size specified for a binding was too small, resulting in one or more column values being truncated. Errors in the OLAP storage engine: An error occurred while the 'Fiscal Quarter' attribute of the 'Time' dimension from the MyCube' database.

Généralement, ce message survient lorsque le dimensionnement des types de nos attributs ne correspond pas à celui des colonnes de la base de données source. Après avoir vérifié plusieurs fois et sur tous les attributs de notre dimension, il en résulte que tout est bien fait. Donc après avoir injustement accusé un de mes collègues, l'attribut en question est supprimé, puis recrée. Oh miracle, le problème de processing disparaît. Bref, impossible de savoir d'où cela vient.

A mes yeux, il n'y a plus qu'une solution pour trouver la source du problème : faire un différentiel du XML entre les deux versions des dimensions. En faisant cela, on se rend compte que la traduction associé à l'attribut Fiscal Quarter possède le bon DataType, mais pas le bon DataSize.

Conclusion : cela vient du fait que le type de l'attribut a été modifié après la mise en place de la traduction. Ce procédé n'entraîne donc pas une mise à jour automatique des objets associés (tels que ceux de la traduction). La seule possibilité pour contourner le problème est de supprimer puis recréer la traduction pour l'attribut. Pas cool, sauf si vous connaissez une solution plus simple.

Comportement du Many to Many avec plusieurs dimensions de jointure

Chez nos clients préférés, nous tombons bien souvent sur une modélisation un peu bizarre d'un cube AS. Bien sûre, il y a toujours une justification à cela car cette modélisation a été mise en place pour répondre à un besoin bien précis.
Voici ladite modélisation (ça sera notre cas n°1) :

Un nouveau must read sur AS

Je n'ai pas pour habitude de le faire, mais j'annonce la publication d'un nouveau livre blanc : AS Operations Guide
J'étais justement en train d'écrire un article assez détaillé qui résume la configuration à apporter à AS dans un environnement gros serveurs et multi-users, ce que je fais depuis un an chez mon client. C'est plus la peine maintenant, les informations se trouvent dans ce document.
C'est un peu aussi pour me justifier du laps de temps entre maintenant et mon dernier post, je l'admets. Mais des documents de cette qualité vous enlève toute volonté d'en écrire pour le moment (je l'avoue, c'était un objectif :) )., surtout quand on voit la liste des auteurs.
Bravo à eux.

Attach/Detach manuel sur SSAS 2005

Le procédé de mise en ligne/mise hors ligne ou Attach/Detach d'une base (bien pratique quelque fois) est une feature apparue à partir de 2008.
Forcément en 2005, gros soucis pour réaliser cette opération, d'où mon problème du jour : la réinstallation d'une instance AS 2005 dont seuls les disques de données de l'ancienne instance ont été conservés (avec les répertoire ".db", c'est déjà ça) : bien entendu, on veut récupérer ces bases dont on ne dispose pas de backups (seulement les répertoires contenant les data file).

Si vous gérez vos instances 2005 avec SSMS 2008, effectivement, dans le menu contextuel il y a bien possibilité de faire un Detach de votre base : autant vous dire tout de suite que ça ne fonctionne pas.

Donc deux solutions :

• Soit vous modifiez dans le fichier de configuration de votre instance AS la propriété Datadir en renseignant le chemin du répertoire qui contient vos anciennes données, puis redémarrage de l'instance pour prendre en compte cette modification, puis backup des bases, puis re-changement du Datadir avec le chemin du répertoire de données initial, puis re-redémarrage de l'instance et enfin un Restore des backups nouvellement créés. Méthode la plus propre, mais lourde, surtout si vous avez 20 bases à sauvegarder puis à remonter.
• Ou L'AUTRE méthode, un peu plus brutale mais qui permet de gagner du temps : un copier-coller des anciens répertoires ".db", des fichiers XML ".db.xml", du master.vmp et du CryptKey.bin dans votre répertoire de données actuel, un redémarrage de l'instance et le tour est joué. Bien entendu, ceci fonctionne avec une instance "à vide", sans base de données présente au préalable. Sinon, elle seront supprimées au redémarrage de l'instance car non référencées dans le nouveau (ancien) fichier master.vmp.

Changer la base SSAS par défaut

Voici le problème auquel j’ai été confronté : des utilisateurs requêtant AS via Excel, disposent d’une chaîne de connexion sur cette instance AS sans avoir précisé la base de données (mot clé Catalog absent de la connection string : à éviter). Après quelques heures d’utilisation, ils se rendent compte que leurs chiffres ne sont pas bons et pour cause. La veille, de nouvelles versions de leurs bases de données avaient été livrées dans un ordre qui, je ne sais pas pourquoi, a fait changer la base dite par défaut. Du coup, leurs requêtes attaquaient la mauvaise base de données (le Catalog n’étant pas précisé, la base par défaut est utilisée).

Ma question : comment déterminer la base qui est utilisée par défaut par notre instance ? Sur SQL, une requête du type Exec sp_defaultdb @loginame='monLogin', @defdb='maBase' permet de modifier ce paramètre facilement. Je n’ai pas trouvé l’équivalent sur SSAS, en tous les cas pas en 2005 (je n’ai pas regardé pour 2008 et 2008R2).

En fouillant un peu dans les fichiers xml d’AS, j’ai trouvé la solution. Chaque base de données possède un fichier qualifié de « référence » pour l’ensemble de l’instance. Le nom de ce fichier est de la forme NomDeMaBaseAS.db.xml. Il contient entre autre le nom et l’ID de la base, les paramètres de traduction, les annotations, etc. Il contient également une propriété qui se nomme Ordinal, et qui précise justement la place de la base de données parmi les autres via un numéro. Si l’ordinal est 0, cette base sera la première, 1 la seconde et ainsi de suite. La base possédant le plus petit ordinal sera celle qui sera considérée comme étant celle par défaut. Il suffit donc de s’arranger pour que la base que vous souhaitez définir comme étant celle par défaut possède le plus petit ordinal. Fastidieux quand il y a beaucoup de base de données (une petite astuce pour éviter d'avoir à parcourir tous les fichiers pour trouver le plus petit ordinal consiste à donner une valeur négative à l'ordinal de la base par défaut : ça marche). C’est pour cela que si jamais vous connaissez une autre solution, je suis preneur. Autre précision, je ne sais pas comment sont déterminés ces ordinaux au moment des déploiements.