Lock en PROD avec un SELECT

bonjour a Tous

Question bête mais je la pose quand même :D:

- Peut on faire un lock avec un SELECT ?

je pose cette question car je refais tous les droits sur tous les serveurs, et j'hesite si je donne les droits aux developpeurs en select en PROD voila tout :)

merci a vous et bonne journée

Bonjour,

Comme toute requête, un SELECT pose effectivement des verrous.
Il s'agit toutefois en général de verrous partagés ayant un impact moins important sur les autres requêtes, mais cela dépendra du niveau d'isolation des transactions

Ceci dit, les verrous posés ne seront surement pas votre principal souci. Autoriser des requêtes - même des simples SELECT peut perturber la production : suppression de données en cache lors d'une grosse requête mal écrite, monopolisation des ressources, génération de nombreux plan de requêtes adhoc... tout un tas de choses qui rendront les diagnostics plus difficiles.

La question est donc : vos développeurs ont-ils réellement besoin de se connecter sur la production, et si oui, pourquoi ?

Citation:

---

Envoyé par olivtone

je pose cette question car je refais tous les droits sur tous les serveurs, et j'hesite si je donne les droits aux developpeurs en select en PROD voila tout :)

---

Perso, ce n'est même pas une question à se poser, c'est non. Il n'y a pas de raisons à donner ce genre de droits. Ils ont besoin d'infos ou une copie d'une DB/Table alors le DBA le fournira. Je ne connais pas la taille et la politique de ton entreprise, mais travaillant pour des grands groupes, c'est juste pas pensable :-)

Voici ce que l'on peut faire avec un petit select malintentionné à base de produits cartésiens :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

select * from dbo.UneTable as A0 JOIN dbo.UneTable as A1 on 1=1 JOIN dbo.UneTable as A2 on 1=1 JOIN dbo.UneTable as A3 on 1=1 JOIN dbo.UneTable as A4 on 1=1 JOIN dbo.UneTable as A5 on 1=1 JOIN dbo.UneTable as A6 on 1=1 JOIN dbo.UneTable as A7 on 1=1 JOIN dbo.UneTable as A8 on 1=1 JOIN dbo.UneTable as A9 on 1=1

---

Avec une bête table de 1 000 lignes, ça retourne 10^30 lignes avec le temps de process plus le passage par le réseau du résultat... :aie:

Bonjour,

Il y a aussi l'autre face de la pièce : un module de requêtage offert au client, avec tout ce que cela peut produire comme problèmes, dont ceux évoqués ici.
Donc, si tout cela est bien compris, on peut douter comme Janlouk de la nécessité de requêter les données de production; en d'autres termes : qu'est-ce qui justifie l'accès à ces données en temps réel ?
Si c'est bien nécessaire, est-ce que ça ne devrait pas être implémenté et contrôlé par une application ? C'est à la limite de l'incitation au vol de données ...

Une fois tout cela pris en considération, est-ce que les utilisateurs ont besoin d'accéder à toutes les tables de la base de données ? Très certainement pas.
Dès lors on peut créer des vues qui filtrent les données qu'ils doivent / ne doivent pas voir, et leur octroyer le droit SELECT sur ces vues.
Si vous êtes sous SQL Server 2016, vous pouvez aussi penser au filtrage dynamique (cf. CREATE SECURITY POLICY & Row-Level Security).

Enfin pour limiter la casse au niveau des performances et de la concurrence d'accès :

• Utiliser le niveau d'isolation de transaction SNAPSHOT avec l'option de base de données ALLOW_SNAPSHOT_ISOLATION à ON, ou bien directement l'option READ_COMMITTED_SNAPSHOT à ON
• Si vous êtes en édition Enterprise, utilisez le gouverneur de ressources
• Plus compliqué à mettre en place : utiliser l'option de session SET SHOWPLAN_XML à ON pour récupérer le plan estimé, et utiliser le nombre de lignes retourné et le coût du lot pour décider de son exécution.

@++ ;)

merci de vos retours

je me suis trompé ce n'etait pas pour les developpeurs les acces en PROD desole

Merci encore, je navais pas pensé a toutes ces faces cachés d'un simple SELECT en PROD