Dans un scénario d'entrepôt de données, l'utilisation de WITH (NOLOCK) présente-t-elle un inconvénient?

Question

J'ai un fichier de style Kimball (faits et dimensions dans les modèles en étoile - pas de lignes ou de colonnes de faits arrivés en retard, pas de dimensions modifiées, sauf la date d'expiration dans le cadre des dimensions à évolution lente de type 2) avec un traitement quotidien lourd d'insertion et de modification. mettre à jour les lignes (aux nouvelles dates) et les processus de reporting mensuel et quotidien. Les tables de faits sont partitionnées en fonction des dates pour faciliter la suppression des anciennes données.

Je comprends que le WITH (NOLOCK) peut entraîner la lecture de données non validées. Toutefois, je ne souhaite pas non plus créer de verrou susceptible de provoquer l'échec ou le blocage des processus ETL.

Dans tous les cas, lorsque nous lisons à partir du DW, nous lisons à partir de tables de faits pour une date qui ne changera pas (les tables de faits sont partitionnées par date) et de tables de dimensions pour lesquelles les attributs ne sont pas modifiés. sont liés à.

Alors, y a-t-il des inconvénients? - peut-être dans les plans d'exécution ou dans le fonctionnement de telles requêtes SELECT ne fonctionnant que parallèlement à partir des mêmes tables.

Answer 1

Tant que les données ne sont pas mises à jour, il n'y a pas de problème, mais je serais surpris de constater les avantages qui en découlent. Je dirais que ça vaut le coup d'essayer. Le pire qui puisse arriver, c’est que vous obtiendrez des données incomplètes et / ou incohérentes si vous êtes au milieu d’une insertion de lot, mais vous pouvez décider si cela invalide quelque chose d’utile.

Answer 2

Voici ce dont vous avez probablement besoin:

`ALTER DATABASE AdventureWorks     SET READ_COMMITTED_SNAPSHOT ON;

ALTER DATABASE AdventureWorks     SET ALLOW_SNAPSHOT_ISOLATION ON; `

Alors allez-y et utilisez

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

dans vos requêtes. Selon BOL:

Le comportement de READ COMMITTED dépend du paramètre de l'option de base de données READ_COMMITTED_SNAPSHOT:

Si READ_COMMITTED_SNAPSHOT est défini sur OFF (valeur par défaut), le moteur de base de données utilise des verrous partagés pour empêcher d'autres transactions de modifier des lignes lorsque la transaction en cours exécute une opération de lecture. Les verrous partagés empêchent également l'instruction de lire les lignes modifiées par d'autres transactions jusqu'à ce que l'autre transaction soit terminée. Le type de verrou partagé détermine quand il sera libéré. Les verrous de ligne sont libérés avant le traitement de la ligne suivante. Les verrous de page sont libérés à la lecture de la page suivante, et les verrous de table à la fin de l'instruction.

Si READ_COMMITTED_SNAPSHOT est défini sur ON, le moteur de base de données utilise le contrôle de version de ligne pour présenter chaque instruction avec un instantané transactionnel cohérent des données telles qu'elles existaient au début de l'instruction. Les verrous ne sont pas utilisés pour protéger les données des mises à jour par d'autres transactions.

J'espère que cette aide. Raj

Answer 3

Avez-vous envisagé de créer un INSTANTANÉ DE LA BASE DE DONNÉES de votre DW et Exécuter vos rapports?

Answer 4

Oui. Votre code SQL sera beaucoup moins lisible. Vous allez inévitablement manquer quelques astuces NOLOCK, car les commandes SQL SELECT utilisant la stratégie NOLOCK doivent la mettre partout.

Vous pouvez obtenir la même chose en définissant le niveau d'isolement .

DÉFINITION DU NIVEAU DE TRANSACTION ISOLATION

En fin de compte, vous obtenez 10% de performances en plus (désolé, je suis trop paresseux pour rechercher l'article, mais il est disponible)

Je dirais qu'un gain de 10% ne vaut pas une réduction de la lisibilité.

Answer 5

Si la création de la base de données entière en lecture seule est possible, il s'agit d'une meilleure option. Vous obtiendrez des performances en lecture sans engagement sans avoir à modifier tout votre code.

ALTER DATABASE adventureworks SET read_only

Answer 6

NOLOCK effectue une & # 8216; lecture sale & # 8217; (indécemment, READ UNCOMMITTED fait la même chose que NOLOCK). Si la base de données est mise à jour au fur et à mesure de votre lecture, vous risquez de recevoir des données incohérentes. La seule option consiste à accepter le verrouillage et donc le blocage ou à choisir l'un des deux nouveaux niveaux d'isolation proposés à partir de SQL 2005 discuté ici .