Archives pour la catégorie Entretien

[SQL Serveur] Liens concernant la migration 2000-2005.

Vidéo Microsoft sur la migration 2000-2005 :
http://www.microsoft.com/france/vision/WebcastTechNetTechDays.aspx?EID=fd12de03-6bb2-435b-a135-da0db259d8d3

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/

[SQL Serveur 2005]Gerer la fragmentation des index.

Toute l’information sur les index et la fragmentation est fourni par la procedure :

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;

[SQL Serveur 2000] Comment Réindexer ?

Une des taches d’ administration les plus simple que le développeur oublie systématiquement de mettre en place et qui entraîne des pertes de performance importante après plusieurs mois de mise à jour de la base.

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

Comment Attacher/Détacher une base à une instance ?

Savoir faire INDISPENSABLE A SAVOIR POUR MIGRER D’une version à une autre.

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.

En ligne de commande: <br />
EXEC sp_attach_db @dbname ='AdventureWorks',@filename1 = 'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQLData\AdventureWorks_Data.mdf',@filename2 = 'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQLData\AdventureWorks_Log.ldf' <br />
 <br />
Détacher: <br />
En ligne de commande: <br />
EXEC SP_DETACH_DB 'AdventureWorks'

[SQL Serveur 2000] Comment effectuer simplement une migration entre SQL Serveur 2000 et 2005 ?

De nombreuses entreprises ont encore leurs serveurs de production sur sql serveur 2000, voir même dans certains cas, sur sql serveur 7. Il devient important de migrer vers sql serveur 2005. D’abord, sql serveur 2008 sortira en août. Ensuite, Microsoft a annoncé la fin de son support sur sql serveur 2000 pour avril 2008.
Lire la suite

BCP

Export des données d’une table vers un fichier.

-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

Spécification d’un mode de récupération.

Un mode de récupération est une option de configuration de bases de données qui contrôle la façon dont les transactions ( insert,update,delete ) sont journalisés dans le fichier de log, s’il est effectué une sauvegarde du journal des transactions et quelles sont les options de récupération disponible. Le mode de récupération retenu pour votre base de données possède des implications à la fois sur la récupération de la base de données et sur les performances, en fonction de la journalisation effectuée ou non par le mode.

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 }

DBCC CHECKDB

Tout DBA de production qui se respecte exécute DBCC CHECKDB avant chaque sauvegarde de nuit.

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