July 2008 / Juillet 2008
La raison d’être du fichier journal (transaction log file) est d’écrire toutes les informations nécessaires pour récupérer les transactions de la base de données. Chaque b.d. doit posséder au moins un fichier journal. Récemment, pour un projet, nous avons eu le besoin de lire ces fichiers journaux et les archiver.
L’archivage des fichiers journaux donne l’option, à l’aide d’un logiciel comme Lumigent Log Explorer, de rechercher à l’intérieur de n`importe quelle fichier transaction log afin de récupérer des données (point-in-time restore). Ceci nous donne une idée exactement les valeurs avant/après un changement, qui/quel application a fait ces changements et permet aussi de récupérer des valeurs ou modifications spécifiques.
Why do you care, as a developer, about what is happening in the transaction log? Un atout des informations dans le fichier journal, qui est de plus en plus exploité par des logiciels tiers personne, est le coté audit – donc il est possible à déboguer ce qui s’est passé sur telle journée au passé (often just disregarded as a mystery) parce que nous interrogeons le fichier journal directement, de même si cela est archivé. Ceci nous est la même principale qu’Érasme nous a expliqué lors de sa collection de Proverbes. ‘Leave no stone unturned’ – litterally we can read everything that has happened. Mais, attention : ne courrez pas toutes à la fois demander votre friendly DBA de lire les fichiers journaux, parce qu’il faut que la b.d. soit dans le bon mode de récupération (recovery model) déjà. Souvent les b.d.s sont en mode de récupération élémentaire (simple recovery mode). Il est même possible, grâce a Log Explorer de mettre toute les transactions par groupe dans une table afin de faire une requête.
Le fichier Transaction Log nous aide aussi à voir quand et quoi change – en plus l’outil Lumigent Log Explorer nous permet d’envoyer un courriel à chaque fois vous faites une command DDL, alors au fur et à mesure nous, en tant que DBA, regarde ces courriels afin de filtrer ce que n’est pas conforme aux normes de la programmation, au bien mieux, nous allons envoyer un exemple pertinent qui vas vous aider durant le développement. Cette approche aidera d’améliorer votre environnent progressivement, un objet à la fois.
Pour en savoir plus / more info :
http://www.sqlservercentral.com/articles/Design+and+Theory/63350/
http://msdn.microsoft.com/en-us/library/ms189085.aspx - Log behavior under different recovery models
http://www.youtube.com/watch?v=ZM44LUuA6hc - video how transaction logs work overview (simplifié)
http://www.youtube.com/watch?v=nyz0AYCwhtM&feature=related - transactions
Merci et n’hésitez pas de me revenir avec vos questions – there are no dumb questions :)
Tuesday, July 29, 2008
Thursday, July 24, 2008
T-SQL Try / Catch utilisation SQL Server usage
Mai 2008 / May 2008
Meilleures pratiques SQL Serveur - try/catch - the best way to handle exceptions in SQL 2005/8
Bonjour à tous / Hi SQL error handlers,
L’objectif de ce posting est de vous expliquer comment gérer les erreurs en langage Transact-SQL. Ceci est similaire à la gestion des exceptions dans l’environnement Visual studio.
Ainsi, nous recommandons d’imbriquer dans le bloc Begin/End Try du code T-SQL, le bloc Begin/End Catch :
Begin Try
Bloc du code T-SQL
End Try
--En cas d’erreur dans le bloc Begin / End Try,
--le système entre dans le bloc Begin/End Catch (as soon as there is an error):
Begin Catch --
Bloc du code T-SQL -- à l’intérieur de cette partie du code, sysfuntions
-- ici Error_Number/Severity/State/Procedure/Line/Message() sont utiles
End Catch
La méthode de contrôle typique est le Begin Transaction/Commit, mais aussi nous vous recommandons la méthode par bloc Try/Catch (que vous voyez déjà en V.S.). An exception will not automatically cause the transaction to rollback - this is a common myth...things will keep running afterwards and a commit will happen with the part of code you really needed to run before. Use XACT_ABORT whenever you are not using TRY/CATCH and are dealing with transactions (thanks to Adam Machnic MVP for clarifying this). On utilise seulement un des deux: set XACT_ABORT ON ou Try/Catch
N.B. Les erreurs de compilation ou de syntaxe ne sont pas comprises/enregistrées lors du try/catch. Il faut donc s’assurer de corriger les erreurs de ce type avant d’imbriquer dans les blocs Try/Catch - it's used to handle transactions that are prone to exceptions. If you have logical errors, then TRY/CATCH is not your saviour.
Références / references :
http://msdn.microsoft.com/en-us/library/ms175976.aspx
http://www.sql-server-performance.com/articles/per/deadlock_sql_2005_p1.aspx TRY/CATCH Helps to Resolve Deadlocks
http://www.databasejournal.com/features/mssql/article.php/3587891
http://blog.sqlauthority.com/2007/04/11/sql-server-2005-explanation-of-trycatch-and-error-handling/
Meilleures pratiques SQL Serveur - try/catch - the best way to handle exceptions in SQL 2005/8
Bonjour à tous / Hi SQL error handlers,
L’objectif de ce posting est de vous expliquer comment gérer les erreurs en langage Transact-SQL. Ceci est similaire à la gestion des exceptions dans l’environnement Visual studio.
If you are used to using @@error raiserror in previous versions of SQL Server, then the best thing for you to use is TRY/CATCH. Not to be used everywhere, just when you have to run multiple inserts/updates that are critical and that you anticipate errors for that code. For just a single insert/update within a proc, then just use begin / end and don't go crazy with it everywhere.
Ainsi, nous recommandons d’imbriquer dans le bloc Begin/End Try du code T-SQL, le bloc Begin/End Catch :
Begin Try
Bloc du code T-SQL
End Try
--En cas d’erreur dans le bloc Begin / End Try,
--le système entre dans le bloc Begin/End Catch (as soon as there is an error):
Begin Catch --
Bloc du code T-SQL -- à l’intérieur de cette partie du code, sysfuntions
-- ici Error_Number/Severity/State/Procedure/Line/Message() sont utiles
End Catch
La méthode de contrôle typique est le Begin Transaction/Commit, mais aussi nous vous recommandons la méthode par bloc Try/Catch (que vous voyez déjà en V.S.). An exception will not automatically cause the transaction to rollback - this is a common myth...things will keep running afterwards and a commit will happen with the part of code you really needed to run before. Use XACT_ABORT whenever you are not using TRY/CATCH and are dealing with transactions (thanks to Adam Machnic MVP for clarifying this). On utilise seulement un des deux: set XACT_ABORT ON ou Try/Catch
N.B. Les erreurs de compilation ou de syntaxe ne sont pas comprises/enregistrées lors du try/catch. Il faut donc s’assurer de corriger les erreurs de ce type avant d’imbriquer dans les blocs Try/Catch - it's used to handle transactions that are prone to exceptions. If you have logical errors, then TRY/CATCH is not your saviour.
Références / references :
http://msdn.microsoft.com/en-us/library/ms175976.aspx
http://www.sql-server-performance.com/articles/per/deadlock_sql_2005_p1.aspx TRY/CATCH Helps to Resolve Deadlocks
http://www.databasejournal.com/features/mssql/article.php/3587891
http://blog.sqlauthority.com/2007/04/11/sql-server-2005-explanation-of-trycatch-and-error-handling/
SQL Server 2005/8 query hints - utilisation With (Nolock)
Avril 2008
Meilleures pratiques SQL Server 2005/8 query hints - utilisation With (Nolock)
Bonjour,
Afin de continuer dans la lignée de mes communications précédentes, vous trouverez ci-dessous de l’information au sujet de WITH (NOLOCK) :
Nous avons tous besoin d’exécuter nos requêtes plus rapidement – certainement pour les départements qui pense Rapid Development avant tout. Voila la raison pour laquelle ma recommandation de ce mois est d’utiliser le query hint WITH (NOLOCK).
Mes collègues et moi sommes d’accord pour dire qu’il existe des raisons d’avoir WITH (NOLOCK) en production, à condition d’avoir des données qui ne risquent pas d’être changées (tables en lecture seulement). C’est important que vous voyiez les données comme elles sont – uncommitted. S’il y a une possibilité que les données changent pendant que vous exécutez vos requêtes, ne surtout pas utiliser les résultats en production parce que vous allez avoir des résultats non valides (Dirty Reads - so your data risks to be inconsistent, and might even skips rows or show duplicates in the results).
Pour en savoir plus :
http://www.sqlservercentral.com/articles/Performance+Tuning/2764/
http://www.sqlservercentral.com/Forums/Topic330889-192-1.aspx vous trouverez dans ce site beaucoup d’informations.
Exemple :
SELECT Orders.OrderID
,Orders.OrderDate
,Products.ProductID
,Products.ProductDescription
FROM db.schema.Orders WITH (NOLOCK)
-- sur une grande table on verra les lignes plus rapidement
INNER JOIN db.schema.Products WITH (NOLOCK)
Attention – Ne jamais utiliser WITH (NOLOCK) sur des tables qui contiennent les types de données en colonnes NTEXT, TEXT, ou IMAGE – vous aurez alors l’erreur 7105 système d’exploitation, processeur en sollicitation excessive (excessive cpu usage, which I have seen flip cluster nodes).
Meilleures pratiques SQL Server 2005/8 query hints - utilisation With (Nolock)
Bonjour,
Afin de continuer dans la lignée de mes communications précédentes, vous trouverez ci-dessous de l’information au sujet de WITH (NOLOCK) :
Nous avons tous besoin d’exécuter nos requêtes plus rapidement – certainement pour les départements qui pense Rapid Development avant tout. Voila la raison pour laquelle ma recommandation de ce mois est d’utiliser le query hint WITH (NOLOCK).
Mes collègues et moi sommes d’accord pour dire qu’il existe des raisons d’avoir WITH (NOLOCK) en production, à condition d’avoir des données qui ne risquent pas d’être changées (tables en lecture seulement). C’est important que vous voyiez les données comme elles sont – uncommitted. S’il y a une possibilité que les données changent pendant que vous exécutez vos requêtes, ne surtout pas utiliser les résultats en production parce que vous allez avoir des résultats non valides (Dirty Reads - so your data risks to be inconsistent, and might even skips rows or show duplicates in the results).
Pour en savoir plus :
http://www.sqlservercentral.com/articles/Performance+Tuning/2764/
http://www.sqlservercentral.com/Forums/Topic330889-192-1.aspx vous trouverez dans ce site beaucoup d’informations.
Exemple :
SELECT Orders.OrderID
,Orders.OrderDate
,Products.ProductID
,Products.ProductDescription
FROM db.schema.Orders WITH (NOLOCK)
-- sur une grande table on verra les lignes plus rapidement
INNER JOIN db.schema.Products WITH (NOLOCK)
Attention – Ne jamais utiliser WITH (NOLOCK) sur des tables qui contiennent les types de données en colonnes NTEXT, TEXT, ou IMAGE – vous aurez alors l’erreur 7105 système d’exploitation, processeur en sollicitation excessive (excessive cpu usage, which I have seen flip cluster nodes).
Meilleures pratiques SQL Serveur 2005 - les schémas en tant que 'containers d'objets'
Mars 2008
Bonjour,
Pour continuer avec les meilleures pratiques sur le thème du mois dernier :
Vous-avez probablement remarqué le changement depuis la version SQL Serveur 2000 à propos de Bd.schema.objet - anciennement Bd.ObjectOwner.Objet. Le Object Owner posait un problème lorsque l’utilisateur quittait la compagnie. Désormais, avec le schéma, qui est un regroupement d’objets, il est possible de bénéficier de certains avantages.
Exemple :
Grant select, insert, update, execute on SchemaName :: to joblow
Quand on crée l’objet, on peut l’associer à un schéma et la sécurité à l’intérieur peut-être appliqué facilement.
Avantages :
· Ceci permet d’obtenir plus de détails sur l’objet (lisibilité facile). Si cette pratique est correctement utilisée, on sait à quel groupe ou à quelle application l’objet appartient.
· Il est alors plus facile de gérer la sécurité sur ces objets. En effet, donner DBO n’est pas toujours la bonne solution (schéma dbo existe encore) – si vous voulez donner plus de droits en exception voir EXECUTE AS
Références
· Granularity like sugar would be sweeter than the same L’article démontre que le monde n’est pas parfait après la utilisation des schémas, mais il est one step on the right direction for db security administration and readability
· http://www.sqljunkies.com/WebLog/outerjoin/archive/2006/02/24/17635.aspx
· http://www.sqlteam.com/article/understanding-the-difference-between-owners-and-schemas-in-sql-server
Bonjour,
Pour continuer avec les meilleures pratiques sur le thème du mois dernier :
Vous-avez probablement remarqué le changement depuis la version SQL Serveur 2000 à propos de Bd.schema.objet - anciennement Bd.ObjectOwner.Objet. Le Object Owner posait un problème lorsque l’utilisateur quittait la compagnie. Désormais, avec le schéma, qui est un regroupement d’objets, il est possible de bénéficier de certains avantages.
Exemple :
Grant select, insert, update, execute on SchemaName :: to joblow
Quand on crée l’objet, on peut l’associer à un schéma et la sécurité à l’intérieur peut-être appliqué facilement.
Avantages :
· Ceci permet d’obtenir plus de détails sur l’objet (lisibilité facile). Si cette pratique est correctement utilisée, on sait à quel groupe ou à quelle application l’objet appartient.
· Il est alors plus facile de gérer la sécurité sur ces objets. En effet, donner DBO n’est pas toujours la bonne solution (schéma dbo existe encore) – si vous voulez donner plus de droits en exception voir EXECUTE AS
Références
· Granularity like sugar would be sweeter than the same L’article démontre que le monde n’est pas parfait après la utilisation des schémas, mais il est one step on the right direction for db security administration and readability
· http://www.sqljunkies.com/WebLog/outerjoin/archive/2006/02/24/17635.aspx
· http://www.sqlteam.com/article/understanding-the-difference-between-owners-and-schemas-in-sql-server
Meilleure pratique : nom complet des objets dans le code / Use fully qualified object names
Février 2008
Bonjour cher(s) lecteurs du Database Hive,
Pour le bienêtre de vos systèmes SGBDR SQL Serveur, veuillez s’il vous plaît indiquer le nom complet des objets dans le code Transact-SQL (Full qualified object names).
Exemple :
SELECT DISTINCT c.CustomerID, s.Name
FROM Sales.dbo.Customer c
JOIN Sales.dbo.Store s ON ( c.CustomerID = s.CustomerID)
WHERE c.TerritoryID = 1
Voici quelques raisons pour vous motiver à suivre cette pratique :
· Clarté du code (on voit clairement d’où vient cet objet)
· Performance réf : http://www.sqlservercentral.com/articles/T-SQL/62061/
· Ne pas le faire est l’une des pires pratiques http://www.sqlservercentral.com/articles/Miscellaneous/worstpracticenotqualifyingobjectswiththeowner/1309/ )
· Le producteur du SGBDR le recommande aussi fortement : “In SQL Server Books Online, many Transact-SQL examples are simplified by not using qualified names. Although these elements are left out of the examples to help readability, we recommend that you use qualified names in Transact-SQL statements in production systems”
Bonjour cher(s) lecteurs du Database Hive,
Pour le bienêtre de vos systèmes SGBDR SQL Serveur, veuillez s’il vous plaît indiquer le nom complet des objets dans le code Transact-SQL (Full qualified object names).
Exemple :
SELECT DISTINCT c.CustomerID, s.Name
FROM Sales.dbo.Customer c
JOIN Sales.dbo.Store s ON ( c.CustomerID = s.CustomerID)
WHERE c.TerritoryID = 1
Voici quelques raisons pour vous motiver à suivre cette pratique :
· Clarté du code (on voit clairement d’où vient cet objet)
· Performance réf : http://www.sqlservercentral.com/articles/T-SQL/62061/
· Ne pas le faire est l’une des pires pratiques http://www.sqlservercentral.com/articles/Miscellaneous/worstpracticenotqualifyingobjectswiththeowner/1309/ )
· Le producteur du SGBDR le recommande aussi fortement : “In SQL Server Books Online, many Transact-SQL examples are simplified by not using qualified names. Although these elements are left out of the examples to help readability, we recommend that you use qualified names in Transact-SQL statements in production systems”
Subscribe to:
Posts (Atom)