Verwenden von NOLOCK Hinweis in EF4?

NOLOCK="READ UNCOMMITTED" = schmutzige Lesevorgänge

Ich nehme an, MS weiß, warum sie die Standard-Isolationsstufe als "READ COMMITTED"

NOLOCK, eigentlich jeder Hinweis, sollte sehr vernünftig verwendet werden: nicht standardmäßig.

Ihr DBA ist ein Muppet. Siehe hierzu (SO): Was kann passieren, wenn (nolock) bei jedem SELECT in SQL Server verwendet wird? . Wenn Sie zufällig in einer Bank oder einer Institution arbeiten, bei der ich einen Account habe, lassen Sie es mich wissen, damit ich es schließen kann.

Ich bin Entwickler eines Tools-Teams in der SQL-Organisation von Microsoft. Ich bin in keiner Weise berechtigt, irgendeine offizielle Erklärung abzugeben, und ich bin mir sicher, dass es Menschen in SO gibt, die mehr über diese Dinge wissen als ich. Nichtsdestotrotz biete ich eine freundliche Faustregel an, die dem Thema "Vorzeitige Optimierung ist die Wurzel allen Übels" folgt:

Benutze NOLOCK (oder irgendeinen anderen Frage-Hinweis) nicht, bis du musst. Wenn Sie eine Select-Anweisung haben, die über einen anständigen Abfrageplan verfügt und gut läuft, wenn das System kaum belastet wird, aber langsamer wird, wenn andere Abfragen auf dieselbe Tabelle zugreifen, versuchen Sie, einige NOLOCK-Hinweise hinzuzufügen. Aber verstehen Sie immer, dass Sie das Risiko eingehen, inkonsistente Daten zu erhalten. Wenn Sie eine missionskritische App schreiben, die Online-Banking betreibt oder ein Flugzeug steuert, kann dies inakzeptabel sein. Für viele Anwendungen ist die Perf-Beschleunigung jedoch das Risiko wert. Bewerten Sie jedoch von Fall zu Fall. Benutze sie nicht einfach überall im Raum.

Wenn Sie sich entscheiden, NOLOCK zu verwenden, habe ich Blogged eine Lösung in C # mit Erweiterungsmethoden, so dass Sie eine LINQ-Abfrage einfach ändern können, um NOLOCK-Hinweise zu verwenden. Wenn Sie dies an EF4 anpassen können, senden Sie bitte Ihre Anpassung.

EF4 hat derzeit keine integrierte Möglichkeit, dies zu tun, wenn ef4 alle Ihre Abfragen generiert.

Es gibt Möglichkeiten, wie gespeicherte Prozeduren oder ein erweitertes Inline-Abfragemodell zu verwenden. Dies kann jedoch sehr zeitaufwendig sein.

Ich glaube (und ich spreche hier nicht für Microsoft), dass das Caching die beabsichtigte Lösung von Microsoft ist, um die Belastung des Servers in EF4-Sites zu verringern. Das Lesen von nicht festgeschriebenem Code (oder Nolock), der in ein Framework integriert ist, würde zu unvorhersehbaren Problemen für das erwartete Verhalten von EF4 führen, wenn 2 Kontexte gleichzeitig ausgeführt werden. Das bedeutet nicht, dass Ihre Situation diese Parallelität erfordert.

Es hört sich so an, als ob Sie bei allen SELECTs nach NOLOCK gefragt wurden. Obwohl ich mit früheren Postern übereinstimme, dass dies gefährlich sein kann, wenn Sie irgendwelche Transaktionen haben, die Transaktionen sein müssen, stimme ich nicht zu, dass der DBA automatisch zu einem Muppet wird. Sie könnten gerade ein CMS laufen lassen, das für schmutzige Lese völlig cool ist. Sie können den ISOLATION LEVEL für Ihre gesamte Datenbank ändern, was den gleichen Effekt haben kann.

Der DBA hat möglicherweise nolock für Operationen empfohlen, die NUR selektiert wurden (was in Ordnung ist, besonders wenn ein ORM fehlgeleitet wird und einige dubiose Datendumps gemacht werden). Das Lustigste an diesem Muppet-Kommentar ist, dass Stack Overflow selbst SQL Server in einem READ UNCOMMITTED-Modus ausführt. Schätze, du musst woanders nach Antworten auf deine Probleme suchen?

Sprechen Sie mit Ihrem DBA über die Möglichkeit, dies auf Datenbankebene zu setzen, oder überlegen Sie sich eine Caching-Strategie, wenn Sie sie nur an wenigen Stellen benötigen. Das Web ist immerhin zustandslos, daher kann Nebenläufigkeit oft eine Illusion sein, wenn man es nicht direkt anspricht.

Informationen zu Isolationsstufen

Nachdem ich über ein Jahr mit EF4 gearbeitet habe, werde ich anbieten, dass die Verwendung von gespeicherten Prozeduren für bestimmte Aufgaben kein Hack ist und in bestimmten Situationen absolut notwendig für die Leistung ist.

Unsere Plattform erhält eine Menge Traffic über unsere Website, APIs und ETL-Datenfeeds. Wir verwenden EF hauptsächlich auf unserer Web-Seite, aber auch für einige Back-End-Prozesse. Manchmal macht EF mit der Abfragegenerierung einen guten Job, manchmal ist es schrecklich. Sie müssen sich die generierten Abfragen ansehen, sie in den Abfrageanalysator laden und entscheiden, ob Sie die Operation besser auf eine andere Weise schreiben (gespeicherte Prozedur usw.).

Wenn Sie feststellen, dass Sie Daten über EF verfügbar machen müssen und NOLOCKs benötigen, können Sie mit den NOLOCK Hints immer Ansichten erstellen und die Ansicht für EF freigeben zugrunde liegenden Tabelle. Das Gleiche kann mit Stored Procedures durchgeführt werden. Diese Methoden sind wahrscheinlich etwas einfacher, wenn Sie den Code-First-Ansatz verwenden.

Aber ich denke, dass ein Fehler, den viele Leute mit EF machen, darin besteht, dass das EF-Objektmodell direkt auf das physische (Tabellen-) Modell in der Datenbank abgebildet werden muss. Es geht nicht und hier kommt dein DBA ins Spiel. Lassen Sie ihn Ihr physikalisches Modell entwerfen und arbeiten Sie zusammen, um Ihr logisches Datenmodell zu abstrahieren, das Ihrem Objektmodell in EF zugeordnet ist.

Obwohl dies eine wichtige PITA wäre, können Sie Ihre SQL immer in einer gespeicherten Prozedur ablegen und die Funktionalität erhalten, die Sie benötigen (oder in die Sie gezwungen werden). Es ist aber definitiv ein Hack!

Ich weiß, das ist keine Antwort auf deine Frage, aber ich wollte das nur reinwerfen.

Es scheint mir, dass dies (zumindest teilweise) die Aufgabe des DBA ist. Es ist in Ordnung zu sagen, dass eine Anwendung sich auf eine bestimmte Art und Weise verhalten sollte, und Sie können und sollten sicherlich versuchen, es so zu programmieren, wie es Ihnen gefällt.

Der einzige Weg, um sicher zu sein, ist, dass der DBA mit Ihnen an der Anwendung arbeitet und die DB-Oberfläche erstellt, die er der App präsentieren möchte. Wenn kritische Tabellen als READ UNCOMMITTED abgefragt werden sollen, sollte er helfen, eine Gruppe gespeicherter Prozeduren mit der richtigen Zugriffs- und Isolationsstufe bereitzustellen.

Es ist kein skalierbarer Ansatz, sich auf den Anwendungscode zu verlassen, um jede Ad-hoc-Abfrage korrekt zu erstellen.