Aujourd'hui, je m'attaque à un fleau bien connu du monde TFS : l'utilisation d'une édition SQL Enterprise qui empêche de migrer son TFS vers une édition inférieure (type Standard ou Express).
Tout administrateur TFS, le sait, la solution est simple. Il suffit de supprimer les features Enterprise activées sur les bases de données à migrer. En soit, rien de compliquer. Par contre quand il faut l'appliquer à une un gros volume de collections... cela devient vite rébarbatif.
Pour faciliter la chose, j'ai réalisé un script SQL bien pratique :
-- Déclarations declare @DataBase sysname -- Crusor pour aller chercher les bases de données declare databases_cursor cursor for select db.name from sys.databases as db where db.name like 'tfs_%'; open databases_cursor -- Passer à la base suivante fetch next from databases_cursor into @DataBase while @@FETCH_STATUS=0 begin -- Changement de propriétaire exec('exec [' + @DataBase + '].dbo.prc_EnablePrefixCompression @online = 0, @disable = 1'); -- Passer à la base suivante fetch next from databases_cursor into @DataBase end close databases_cursor deallocate databases_cursor
Note, en plus d'empêcher la migration, si l'édition SQL Server est inapproprié, car induisant des features superflues, on peut contacté un usage de la RAM plus important que ce qu’il devrait être.
Exemple constaté : TFS 2013, SQL 2012, une trentaine de collections, 2 CPU, 4 Gb RAM. Après suppression de la compression, le serveur utilise 11% de RAM en moins et les performances pour les utilsaiteurs sont restées identiques.
Voilà, bonnes migrations ;)