Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

The Mit's Blog

En plus d'intégrer et skier, il sait même écrire !
(Blog de Renaud Comte)

Actualités


  • Ancien MVP SharePoint 8 ans ...
    Des projets .Net, SharePoint 2013 ou Office 365 ??

    Contactez-nous :

Archives

[AVIS] la Base de données SharePoint, la nouvelle boite de Pandore des ITs

http://blogs.codes-sources.com/blogs/fabrice69/WindowsLiveWriter/SharePointLestemplatesVISIOpourlesprojet_D180/image_2.png http://blogs.codes-sources.com/blogs/fabrice69/WindowsLiveWriter/SharePointLestemplatesVISIOpourlesprojet_D180/image_2.png

Comme vous le savez certainement, l' ensemble des données du fonctionnement même de SharePoint 2007 réside dans des bases de données.

  • Base de données de contenu
  • Base de données de configuration
  • Base de données de SSP

Si effectivement, 99% de ces données sont accessibles par les API et les Web Services, il est relativement tentant d'accéder directement au bases de données pour "interagir" avec le système.

Mais voila, il est important de toujours considérer la DB SharePoint comme une vrai boite noire technique, non sa DB SQL si facilement accessible du passé.

Sous entendu, réfréner ses pulsions SQLiennes de fouiller, farfouiller dedans.

Il y a plusieurs raisons :

  • Hors garantie de la license SharePoint et largement déconseillé par le Team Microsoft
  • Aucune documentation clair et viable du MCD
  • La cohérence même de SharePoint tient à celle de la DB

Cette problématique existe depuis le début sous SharePoint, l'un des grands Messieurs du Team SP avait justement posté un grand warning à l'époque

Please Stay Out Of The Database!!!
Our object model is a contract with you.  We’ve gone to a lot of trouble to ensure that using the OM results in stable and performant database interactions.  If anything’s amiss, we’re honor-bound to fix it.  Please, please use it.

Je ne saurais trop vous (re)conseiller de lire et relire le post.

Mais en résumé, si votre DB à une donnée de désynchronisée, ou une information incorrecte dans un flux XML d'un ligne d'une table, vous pouvez vous retrouvez avec une ferme SharePoint caduque ou au fonctionnement aléatoire.

Et la, croyez un pompier SharePointeur de longue date, là, il ne vous reste plus que la hache et les prières pour arriver à redresser votre ferme.

http://fr.wikipedia.org/wiki/Pandore

C'est la que le phénomène de la "boite de Pandore" est le plus criant, car il ne vous reste vraiment que l'espoir pour trouver une solution

Personnellement, je miserais plus sur l'espoir d'un BackUp le plus à jour des DB !

Remarque personnelle : Ne comptez pas trop non plus sur le support d'un expert ou de l'éditeur pour réparer vos bévues. Que vous le cachiez ou pas, si votre ferme de production est bloquée, la solution sera forcement lente et douloureuse. Il n'y a pas de script miracle qui font de la correction chirurgical, ce sera forcement des processus de backup croisé avec de l'analyse de Log et des test à outrance. Bienvenue Dr MD House ...

Mais alors, pourquoi trouvons nous souvent des posts avec pleins de bons conseils et de chaine SQL sur SharePoint ?

...

...

Oh je ne vise personne, j'avoue même que j'ai moi même tapé en direct dans les DBs

Les raisons sont souvent les mêmes, je peux même vous en énumérer les plus connus :

  • Rapidité
    Je me connecte sur l'analyser, et 10 secondes après, je requête tout ce que je peux avoir besoin
  • Simplicité
    Pas besoin de connaître les API ou le CAML, juste à faire du SQL. Et rien a coder ou compiler
  • introspection SharePoint
    Hop, un coup de profiler et je sais tout de mon besoin
  • Veille habitude
    J'ai toujours requêté mes applications pour les corriger, pourquoi changer
  • Perdu pour perdu
    J'ai pas le temps, faut bien que je corrige le truc, j'ai donc pas le choix, donc je le fait
  • ...

Eh oui, c'est vrai qu' écrire 10 lignes de codes sous Powershell, compiler une DLL et pire encore, avoir à comprendre l'architecture logique de SharePoint pour exploiter ensuite le modéle objet peut être largement considérer comme une basse besogne, ou un travail ingrat ...

Limite, pourquoi même faire du SharePoint !

Allons, si vous travailler sur une plateforme, le minimum c'est de la connaître et d'apprendre à la connaître.
>>> La voie de la facilité n'a jamais conduit à l'excellence, jamais !

Mais bon, je vois déjà certaines réactions arriver. Pas de soucis, je sais faire l'avocat du diable (du fait que moi même je l'ai ouvert cette boite de SPandore )

A vrai dire, il y a vraiment quelques situations ou l'accés à la DB ou la recherche au Profiler est souvent difficilement contournable.

Soit :

  • log d'erreur inconsistant et perte de service
    Genre, le moteur de recherche n'indexe plus et le helpdesk est désespéré
  • Tout à été respecté dans le développement mais des erreurs 500 arrivent régulièrement
    Spéciale dédicace aux workflows SPD qui dérapent en volume
  • Soucis de performance sur une action
    Avec Profiler, j'identifie rapidement la donnée qui pose soucis et j'interviens
  • Obtenir des données absente de l'API
    genre log de workflows aggrégé pour analyser par exemple
  • MIGRATION ET IMPORT DE SITE : Certainement mon préféré ! (des 2 cotés du Lac Léman d'ailleurs smile_regular)
    Que faire quand suite à l'import ou l'export d'un site, vous vous retrouvez bloquez par une obscure donnée ou une URL d'un site ID perdu pour toujours ?
    >>> Rien à faire coté API, il faut corriger ou fixer la donnée et enfin pouvoir migrer !

Bref, à chaque fois que vous trouvez un post de log vous orientant vers une approche SQL, il y a souvent une situation de crise ou de blocage.

Pourquoi ?

C'est assez simple en fait. Rare sont ceux qui "joue" avec la DB SharePoint qui ne sont pas :

  • des DBAs confirmés
  • de vrais SharePointeurs
  • des gens d'experience qui ont justement vu des fermes s'écrouler suite à de mauvaise manipulation.

Et donc, ces vrais professionnels agissent naturellement, soit en professionnel de l'informatique et responsable de leurs actes.

Je suis sur que vous voyez ou je veux en venir : ils agissent de manière totalement sécurisé et non frivole.

Personnellement, j'ai jamais vu un montagnard ou un freerider partir en montagne sans son équipement, un arva, de la nourriture, ....
>>> on agit de manière sécurisé face aux risques.

En effet, intervenir au niveau des DBs SharePoint n'est pas à prendre à la légère :

  • Sévérité d'une erreur en DB : Très importante
  • Probabilité d'une erreur en DB : Très importante
  • Donc Risque résiduel : Très élevé

Ainsi, il faut donc sur-sécurisé son intervention et bien le périmètrer.

Quelques exemples, pas de soucis, je suis à votre service :

  1. Bien s'assurer que vos back ups sont à jours et disponibles immédiatement
    >>> Si jamais une mauvaise manipulation casse tout, on remonter ASAP.
    Genre : copie du fichier MDF avant modification et reconnection à chaud de la base si besoin
  2. Ne jamais taper en direct sur la base de production
    >>> si vous avez besoins d'analyser, restorer donc un backup sur votre préprod et travaillez en zone froide, pas chaude
    >>> si vous n'avez pas le choix, limiter les risques de contraintes en passant votre ferme en pause/quiesce. Ainsi, les auteurs ne risquent pas de causer de blocages.
    (http://www.sharepointblogs.com/johnwpowell/archive/2007/07/13/quiescing-can-you-use-it-in-a-sentence.aspx)
  3. Les machines virtuels et les fermes de préproduction sont vos amis
    >>> les 2 sont des éléments jetables, en cas de soucis, vous ne cassez rien. Encore que je constate de moins en moins de pre prod bien sauvegardé ...
     
  4. Limitez vos actions SQL
    >>> les "SELECT" ont peu d'impact sur SharePoint sauf en cas d'upload de données donc le mode quiesce vous protège. Cependant, "DELETE", "UPDATE", "INSERT" eux sont réélement impactant. validez bien ce que vous allez faire en introspectant le comportement de SharePoint via le SQL Profiler avant de tester gracé à votre sens innée de l'experience et l'instinct du SharePointeur

Conclusion

Il faut réellement comprendre le risque important que vous pouvez prendre en accédant en direct dans les bases de données SharePoint. Mais comme dans toute gestion du risque, vous pouvez mettre en place des solutions afin de le limiter et d'eviter le pire.

Ne soyez donc pas trop insouciant, et prevenez le danger en vous assurant que dans tous les cas vous saurez remonter votre ferme SharePoint. De toute maniére, si vous avez une ferme SharePoint, vous devez avoir de véritable processus de restauration et de maintenance de service.

Mais ceci est un autre débat smile_regular

Le mieux reste encore d'eviter de toucher au bases de données. Si vous devez le faire, bien protéger vous le mieux de tout soucis, maintenant, vous êtes prévenus.

Donc

Règle N°1 : ne touchez pas à la DB

Règle N°2 : en cas de blocage, voir la règle N°1

Sinon, faites bien attention, vraiment ! 

Renaud Comte aka TheMit (SParaniaque des DBs SharePoint)
Member of WygTeam
http://www.wygwam.com

Mots clés Technorati : ,,,,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: vendredi 28 novembre 2008 14:14 par themit

Commentaires

ROMELARD Fabrice a dit :

Mouais, c'est bizarre de se sentir si directement visé dans un message.

Pour information, je travaille de plus en plus en PowerShell et de moins en moins en SQL.

Toutes les dernières opérations effectuées en SQL n'ont été que des SELECT, effectuées face à des situations ou personne ne savait comment refaire fonctionner le système (cas du Search) ou comment faire migrer la collection.

Bref, je suis assez d'accord pour ne toucher au SQL que pour de l'urgence et réellement avec une grande attention.

Romelard Fabrice [MVP]

# novembre 28, 2008 14:42

Gribouillon a dit :

Désolé, mais je crois qu'il y a un copyright de Gat sur les jeux de mots à la "SPandore" :-)

Une autre raison qui amène à jeter un oeil à la base SQL : la curiosité. Et comme tu le dis bien, les machines virtuelles sont idéales pour ce genre de choses.

# novembre 28, 2008 18:34
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01