Announcement

Collapse
No announcement yet.

Update auf komplette Tabelle vs. Sperre + timeout in Anwendung

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Update auf komplette Tabelle vs. Sperre + timeout in Anwendung

    Hallo,
    ich mache ein Update auf die vollständige Tabelle ohne Where-Teil, Datensätze mehrere hunderttausend. In der Zeit ist die Anwendung nicht benutzbar. Ich tippe mal drauf dass der MSSQL-Server so schlau ist und denkt die komplette Tabelle zu sperren ist das beste.

    Habe gelesen dass man dann Isolation Level auf Snapshot stellen kann. Wo mache ich das und muss ich dann meine Anwendung umbauen?

  • #2
    Originally posted by openshinok View Post
    Hallo,
    ich mache ein Update auf die vollständige Tabelle ohne Where-Teil, Datensätze mehrere hunderttausend. In der Zeit ist die Anwendung nicht benutzbar. Ich tippe mal drauf dass der MSSQL-Server so schlau ist und denkt die komplette Tabelle zu sperren ist das beste.

    Habe gelesen dass man dann Isolation Level auf Snapshot stellen kann. Wo mache ich das und muss ich dann meine Anwendung umbauen?
    Am besten Direkt nach Backup und Restore, sonst könnte es eine bißchen dauern.
    [HIGHLIGHT="SQL"] DECLARE @Stmt NVARCHAR(MAX);
    SET @Stmt = 'ALTER DATABASE '+ QUOTENAME(DB_NAME())
    + ' SET ALLOW_SNAPSHOT_ISOLATION ON' ;
    EXEC sys.SP_ExecuteSQL @Stmt;
    SET @Stmt = 'ALTER DATABASE '+ QUOTENAME(DB_NAME())
    + ' SET READ_COMMITTED_SNAPSHOT ON ' ;
    EXEC sys.SP_ExecuteSQL @Stmt;[/HIGHLIGHT]
    Zuletzt editiert von ebis; 14.12.2009, 13:41.

    Comment


    • #3
      Hallo openshinok,

      neben der Verwendung von Snapshot-Isolation gäbe es noch die Variante der "Dirty Reads"

      Mit
      [highlight=SQL]
      SELECT *
      FROM Tabelle WITH (NOLOCK)
      -- Alternative
      SELECT *
      FROM Tabelle WITH (READUNCOMMITTED)
      [/highlight]
      kannst Du auch (fast immer) Tabellen lesen, die vollständig gesperrt ist.

      Der Unterschied zum Snapshot (einer von vielen) ist aber, das es eben "Dirty Reads" sind und Du auch Daten/Zustände liest, die kurz später durch ein Rollback wieder rückgängig gemacht werden; eben sehr dirty, dafür vom Verwaltungsaufwand her geringer.

      Man muss halt je Anwendungsfall prüfen, ob solche "unschärfen" akzeptable sind oder nicht; im einer Buchhaltung wäre es nicht akzeptabel.
      Olaf Helper

      <Blog> <Xing>
      * cogito ergo sum * errare humanum est * quote erat demonstrandum *
      Wenn ich denke, ist das ein Fehler und das beweise ich täglich

      Comment


      • #4
        hallo,
        ich werde das mal testen. Die unschärfe ist absolut akzeptabel. Dankeschön euch beiden

        Comment

        Working...
        X