Tutorial sur le conseiller de mise à niveau 2000-2005 :
http://www.asp-php.net/tutorial/sql-server/sqlupgradeadvisor.php

La migration 2000-2005 par christian Robert :
http://blogs.codes-sources.com/christian/archive/2007/03/27/sql-server-migrer-de-2000-2005-les-commandes-indispensables.aspx

Tutorial – La migration par sauvegarde-restauration 2000-2005 :
http://www.technos-sources.com/tutorial-restaurer-base-provenant-backup-moteur-sql-server-2000-37.aspx

Tutorial supinfo – La migration 2000-2005 par Copy Database :

http://www.laboratoire-microsoft.org/articles/server/migration-sql-server-2000-2005/

dm_db_index_physical_stats

Les administrateurs doivent s’intéresser à la colonne avg_fragmentation_in_percent pour déterminer si les index présentent une fragmentation externe. Celle ci est présente pour une valeur supérieur à 10.

Ils doivent examiner la valeur de la colonne avg_page_space_used_in_percent pour déterminer si les index souffrent d’une fragmentation interne. Celle ci est presente si la valeur est inférieur à 75.

Exemple :

DECLARE @database_id int
SELECT database_id,name FROM sys.databases;
Set @database_id = 1
SELECT index_id,avg_fragmentation_in_percent,avg_page_space_used_in_percent FROM sys.dm_db_index_physical_stats(@database_id,NULL,NULL,NULL,’Detailed’)

Si vous constatez que vos index souffrent de fragmentation interne ou externe , vous devez executer regulierement les instruction ALTER INDEX … REBUILD et ALTER INDEX … REORGANIZE.

exemple :

USE Adventuresworks
ALTER INDEX PK_Employee_EmployeeID ON HumanRessource.Employee REORGANIZE;

USE Adventureworks
ALTER INDEX PK_Employee_EmployeeID ON HumanRessource.Employee REBUILD;

Ptit Dje nous fournit un script qui utilise DBCC INDEX DEFRAG et évite de faire chuter les performances de la base lors de l’application. On définit le seuil de fragmentation MAXFRAG à partir de laquelle s’applique la réindexation.

  /*Perform a 'USE <database name>' to select the database in which to run the script.*/
-- Declare variables
SET NOCOUNT ON
DECLARE @tablename VARCHAR (128)
DECLARE @execstr   VARCHAR (255)
DECLARE @objectid  INT
DECLARE @indexid   INT
DECLARE @frag      DECIMAL
DECLARE @maxfrag   DECIMAL   -- Decide on the maximum fragmentation to allow
SELECT @maxfrag = 10.0   -- Declare cursor
DECLARE TABLES CURSOR FOR
   SELECT TABLE_NAME
   FROM INFORMATION_SCHEMA.TABLES
   WHERE TABLE_TYPE = 'BASE TABLE' --and table_name not in ('table_act_entry','table_case')   -- Create the table
CREATE TABLE #fraglist (
   ObjectName CHAR (255),
   ObjectId INT,
   IndexName CHAR (255),
   IndexId INT,
   Lvl INT,
   CountPages INT,
   CountRows INT,
   MinRecSize INT,
   MaxRecSize INT,
   AvgRecSize INT,
   ForRecCount INT,
   Extents INT,
   ExtentSwitches INT,
   AvgFreeBytes INT,
   AvgPageDensity INT,
   ScanDensity DECIMAL,
   BestCount INT,
   ActualCount INT,
   LogicalFrag DECIMAL,
   ExtentFrag DECIMAL)   -- Open the cursor
OPEN TABLES   -- Loop through all the tables in the database
FETCH NEXT
   FROM TABLES
   INTO @tablename   WHILE @@FETCH_STATUS = 0
BEGIN
-- Do the showcontig of all indexes of the table
   INSERT INTO #fraglist
   EXEC ('DBCC SHOWCONTIG (''' + @tablename + ''')
      WITH FAST, TABLERESULTS, ALL_INDEXES, NO_INFOMSGS')
   FETCH NEXT
      FROM TABLES
      INTO @tablename
END   -- Close and deallocate the cursor
CLOSE TABLES
DEALLOCATE TABLES   -- Declare cursor for list of indexes to be defragged
DECLARE indexes CURSOR FOR
   SELECT ObjectName, ObjectId, IndexId, LogicalFrag
   FROM #fraglist
   WHERE LogicalFrag >= @maxfrag
      AND INDEXPROPERTY (ObjectId, IndexName, 'IndexDepth') > 0   -- Open the cursor
OPEN indexes   -- loop through the indexes
FETCH NEXT
   FROM indexes
   INTO @tablename, @objectid, @indexid, @frag   WHILE @@FETCH_STATUS = 0
BEGIN
   PRINT 'Executing DBCC INDEXDEFRAG (0, ' + RTRIM(@tablename) + ',
      ' + RTRIM(@indexid) + ') - fragmentation currently '
       + RTRIM(CONVERT(varchar(15),@frag)) + '%'
   SELECT @execstr = 'DBCC INDEXDEFRAG (0, ' + RTRIM(@objectid) + ',
       ' + RTRIM(@indexid) + ')'
   EXEC (@execstr)       FETCH NEXT
      FROM indexes
      INTO @tablename, @objectid, @indexid, @frag
END   -- Close and deallocate the cursor
CLOSE indexes
DEALLOCATE indexes
DROP TABLE #fraglist
GO

Une solution plus lourde utilisant DBCC Reindex donc entrainant une perte de performance du serveur mais trés efficace car elle recree la totalité des index

USE Mabase
go
DECLARE @TableName varchar(255)
DECLARE TableCursor CURSOR FORSELECT table_name FROM information_schema.tables WHERE table_type = 'base table'
OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
DBCC DBREINDEX(@TableName,' ',90)FETCH NEXT FROM TableCursor INTO @TableName
END
CLOSE TableCursor
DEALLOCATE TableCursor
go 

Attacher:

Aprés téléchargement et décompactage .msi de la base Adventure works. Il reste à attacher cette base à l’instance SQLEXPRESS de sql serveur.

Pour cela, j’utilise SQL Serveur management studio express.

Je me connecte sous mon compte administrateur windows pour éviter les problème de sécurité avec la base Adventure works puisque mon compte sa/pwd n’existe pas sous Adventure works.

Je sélectionne l’onglet database et avec un clic droit, je sélectionne attache…

Il ne reste plus qu’à indiquer le chemin du fichier MDF de la base adventure works.

La video de microsoft sur la migration :

http://www.microsoft.com/france/vision/WebcastTechNetTechDays.aspx?EID=fd12de03-6bb2-435b-a135-da0db259d8d3

Un article de christian robert sur son blog sur la migration :

http://blogs.codes-sources.com/christian/archive/2007/03/27/sql-server-migrer-de-2000-2005-les-commandes-indispensables.aspx

Un tutorial de code sources sur la migration :

http://www.technos-sources.com/tutorial-restaurer-base-provenant-backup-moteur-sql-server-2000-37.aspx

-S précise le nom de l’instance
-T utilise le mode d’authentification windows
-c fichier origine au format texte

exemple :

bcp ssms.dbo.clients out c:clients.txt -c -S Serveur -T
bcp Adventureworks.person.contact out « d:sql serveuradventureworks_person_contact.txt » -S Pluton -U SA -P ******* -T -c

Exporter le résultat d’une requête avec bcp

exemple :

bcp « select ville from ssms.dbo.clients » queryout c:lesvilles.txt -c -S Serveur -U id_utilisateur -P Password

Importer des données avec bcp.

-F La première ligne contient le nom de colonnes, la deuxième ligne les données.
-t précise la tabulation de separation.

exemple :

bcp ssms.dbo.codepostaux in c:codepostal.txt -c -F 2 -t ; -S Serveur -T

Télécharger :

http://www.microsoft.com/downloads/details.aspx?familyid=D07219B2-1E23-49C8-8F0C-63FA18F26D3A&displaylang=en

Tutorial :

http://www.technos-sources.com/tutorial-installation-service-pack-sql-server-2005-43.aspx

Attention! A ce jour, un SP3 existe pour sql server 2005

1 – Trés important.

Si votre base est hautement transactionnelle, nombreux insert, nombreux update, nombreux delete. Vous devez impérativement placer votre fichier de log, le .ldf sous sql serveur, sur un disque séparé.

Si vous êtes en phase de conception, vous pouvez placer vos index non cluster sur un disque different, en effet, la mise à jour passe par 3 étapes, la mise à jour de l’index cluster, la mise à jour des index non cluster, et enfin le journal.

2 – Cas particulier.

Si vous avez des lots de nuits entrainant des mises à jours monstrueuses… vous devez choisir un disque hautement performant pour votre fichier de log. Et vous devez gérer l’espace car votre log va subir des changements de taille important. Eventuellement, vous pouvez choisir le mode de recuperation simple suivant votre gestion de la sauvegarde.

3 – gestion des lots.

Des DBA confirmés vous diront qu’il ne faut pas indexer de façon excessive des tables mises à jour en lot ou tout au moins, vous devez supprimer les index avant et les recreer apres un traitement par lot.

SQL Server 2005 propose trois mode de récupération pour les bases de données :
- complet
- simple
- journalisé en bloc

Dans le mode de récupération complet, le moteur de bases de données journalise toute les opérations sans jamais les tronquer. Ce mode permet de restaurer une base de données au point de défaillance. Il s’agit du mode recommandé pour une base OLTP fortement sollicité. Le journal est vidé à chaque sauvegarde. Toutes les opérations sont journalisés dans le journal.

Dans le mode de récupération simple, le moteur de base de données limite la journalisation de la majorité des transactions et tronque le journal de transaction ( suppression des données ) après chaque point de vérification ( toutes les secondes ). Ce mode ne permet pas de sauvegarder et de restaurer le journal de transaction. Il s’agit d’un mode facile à maintenir car on ne gère guère le journal de transaction, par contre, il ne permet pas de revenir à l’instant t de la défaillance ce que permet la sauvegarde régulière du journal.

Dans le mode de récupération journalisé en bloc, le moteur de base de données journalise de façon minimal les opérations de masse comme select into et bulk insert ( BCP également ). Dans ce mode, si une sauvegarde de journal contient une quelconque opération en bloc, vous pouvez restaurer la base de données à la fin de la sauvegarde du journal, pas à un point déterminé comme dans la journalisation complète. Ce mode doit être employé lors de grosses opérations en bloc.C’est le mode recommandé pour la business intelligence.

EXEMPLE :

ALTER DATABASE MaBase SET RECOVERY { FULL | BULK_LOGGED | SIMPLE }

La commande DBCC CHECKDB effectue différents contrôles sur une base de données afin de vérifier l’allocation, l’intégrité structurelle et l’intégrité logicielle de tous les objets de la base de données.

exemple :

DBCC CHECKDB WITH PHYSICAL_ONLY pour une vérification matériel de la base de données.
DBCC CHECKDB pour une vérification complète.

Sachant qu’il n’existe aucun bug pouvant endommager une base de données sql serveur, on peut généralement se limiter à la première option qui détecte les erreurs matérielle pouvant survenir sur la base. Attention, une corruption de base est un évènement dramatique qui doit être détecté au plus tôt afin d’être réparé.

En cas d’erreur sur la base, vous avez deux option:

La plus prudente, c’est de faire appel à une sauvegarde récente et de la restaurer… si l’erreur se reproduit fréquemment, mettez en doute votre matériel!

La deuxième solution, la moins bonne, c’est de réparer la base avec DBCC CHECKDB. Vous devez savoir que si vous procédez ainsi, vous allez perdre des données pour récupérer l’intégrité du fichier.
Pour cela, je vous renvoie à la documentation de référence : http://msdn.microsoft.com/fr-fr/library/ms176064.aspx