Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

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 ;)