Announcement

Collapse
No announcement yet.

Unerklärliche Timeout Fehler

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

  • Unerklärliche Timeout Fehler

    Hallo!<br>
    <br>
    Wir programmieren unsere Anwendung unter Delphi5 und greifen über ADO/OBDC auf eine Datenbank auf einem SQL-Server 2000 (auf NT4 oder W2k) zu.
    Bei uns in der Firma läuft das Ganze auf einem PIII/600 Server wunderbar in ordentlicher Geschwindigkeit, es gibt keine Timeouts, und wenn, dann nur bei ordentliche Belastung.<br>
    <br>
    Jetzt haben wir Kunden die mit ungefähr 10 Clients auf unsere Datenbank zugreifen, und dort gibt es dann TimeoutFehler teilweise über das komplette Programm.<br>
    <br>
    Nun ist es so, daß wenn der SQL Server neu gestartet ist, der Speicher schön leer ist, und die Anwendung wunderbar schnell läuft. Jetzt schaufelt aber der SQL-Server den ganzen Speicher voll der ihm zugewiesen wird, und gibt diesen aber nicht mehr frei! So müllt sich suksessive der ganze Hauptspeicher bis zur gegebenen Grenze voll, und das Programm wird immer träger, bis am Schluß dann die Timeouts kommen..<br>
    Das Einzige was wir bisher groß als Hilfe gefunden haben ist, daß man nur 50% für den Hauptspeicher an den SQL-Server geben soll, weil bei 100% Speicher, und dann noch swappen, dann ists klar, daß der Server erst recht in die Knie geht.<br>
    <br>
    Was können wir also dagegen tun, daß der SQL Server sich dauernd den Speicher zumüllt? Wie kann man von der Anwendung aus diesen Speicher wieder freigeben? Hat man da über Delphi/ADO überhaupt eine Möglichkeit?<br>
    <br>
    Oder woran können diese Timeouts noch liegen? Weil einige Kunden arbeiten problemlos mit dem Programm, haben auch nicht weniger Clients und berichten, daß sie keine Timeouts bekommen, auch nicht im heftigeren Betrieb.<br>
    <br>
    Ein Kunde berichtete, daß seit dem Eintrag des Benutzers SA in der UDL-Datei liefe das Programm "schneller", sprich ohne Timeouts? Kann das sein? Kann der Benutzer SA SQL-Server intern schneller sein?<br>
    <br>
    Fragen über Fragen.. Leider findet sich im Internet zu diesem Thema recht wenig, ich hoffe ihr könnt uns da ein wenig weiterhelfen..<br>
    <br>
    <br>
    Ciao,<br>
    Markus<br>

  • #2
    Hallo,

    dieser Verhalten ist mir noch nicht untergekommen, wobei ich vermute, dass die "Timeouts" von hängengebliebenen Sperren kommen (d.h. eine SELECT-Abfrage muss warten, bis eine vorherige Transaktion ihre Sperre wieder freigibt).

    Mit welchem Isolation Level und mit welcher Cursor-Art greifen die Clients auf die MS SQL Server-Datenbank zu? Greift die Anwendung in die Transaktionssteuerung ein? Wie gross ist die Datenbank und wie sieht der Primärschlüssel der Tabellen (Anzahl der Spalten und Datentyp) aus?

    &gt;Ein Kunde berichtete, daß seit dem Eintrag des Benutzers SA in der UDL-Datei.....

    Es macht für den SQL Server einen Unterschied, ob der "Eigentümer" der Datenbank bzw. der Datenbank-Objekte zugreift oder ein anderer Benutzer - allerdings nur dann, wenn man in den eigenen SQLs <b>keine</b> qualifizierten Bezeichner für die Datenbank-Objekte angegeben hat. Nur dann, wenn immer der vollständige Name (<i>Owner + . + Name</i>) angegeben wird, darf der SQL Server seine internen Cache für die bereits vorbereiteten SQL-Anweisungen wiederverwenden. Greift nicht der "Eigentümer" zu und verwendet man keine qualifizierten Namen, so muss der SQL Server <br>
    a) jedesmal die Tabelle neu suchen und die Rechte prüfen, und <br>
    b) jedesmal den Optimizer neu starten

    Comment


    • #3
      Hallo,
      vielen Dank für die rasche Antwort.

      Wir greifen mit zwei TADOConnections auf die Datenbank über eine UDL-Datei zu. Die Connections verwenden den Isolationslevel "ReadCommitted". Als Cursor verwenden wir "clUseClient".
      Mit welchen Nachteilen ist bei "ReadUncommitted" zu rechnen?

      Die Anwendung startet in einem try-except-Block die Transaktion, führt als letzte Zeile Commit und im except-Teil Rollback aus. Weitere Eingriffe finden nicht statt.

      Datenbank:
      Größe ist verschieden, von 20 MB bis 600 MB
      insgesamt ca. 200 Tabellen, davon 10 "große" Tabellen
      Der Primärindex ist jeweils das Feld ID (integer).

      Vielen Dank

      Comment


      • #4
        Ergänzende Info zu den Transaktionen:

        Die Transaktionen werden über die gleiche Connection abgewickelt, die den weiteren Queries im Datenmodul zugeordnet ist.

        Kann das evtl. Probleme bei einem Commit verursachen?
        Sollte die Transaktion evtl. mit einer anderen Connection gestartet werden, die sonst nirgends verwendet wird

        Comment


        • #5
          Hallo,

          &gt;Die Anwendung startet in einem try-except-Block die Transaktion..

          welche und wie viele Anweisungen werden in diesem Block ausgeführt?

          &gt;..gleiche Connection abgewickelt, die den weiteren Queries im Datenmodul zugeordnet ist. ..

          ADO hat die Eigenheit, bei Bedarf im Hintergrund neue Verbindungen (Connection-Instanzen) abzuspalten, wenn die vorhandene Verbindung von einer vorherigen Anweisung noch belegt ist. Microsoft hat dieses Feature eingebaut, um die Sache für VB- und ASP-Leute zu vereinfachen. Allerdings laufen diese "unsichtbaren" Verbindungen immer dann aus dem Ruder, wenn die Anwendung eigene Transaktionen verwaltet (und nicht auf die deklarativen Transaktionen von COM+ zurückgreift).

          Ich würde daher zuerst den Profiler des MS SQL Server auf die Lauer legen oder die Anzahl der Datenbankverbindungen über die Leistung-Anzeige von Windows (SQLServer:AllgemeineStatistik) anzeigen lassen

          Comment


          • #6
            clUseClient würde ich nicht nutzen, weil dann ziemlich hoher Traffic im Netz erzeugt wird, setz mal auf clUseServer
            (das habe ich mal bei einem Performance-Vergleich ado-bde, jaja, bde) gelesen.

            Heik

            Comment


            • #7
              Hallo,

              &gt;..clUseClient würde ich nicht nutzen...

              diese pauschale Aussage führt in die Irre. Es gilt bei ADO die folgende Faustformel:

              a) ACCESS-Datenbank: clUseServer <br>
              b) SQL-Datenbank: clUseClient

              In meinem Buch <i>ADO und Delphi</i> kümmert sich das Kapitel 7 auf 30 Seiten nur um das Thema der Cursor. Wie dort zu sehen ist, bleibt clUseServer beim SQL-Server für Sonderfälle vorbehalten - die Einstellung clUseClient ist effektiver (zumal dort das Transaktions-Problem der langen Sperrzeiten vermieden wird). Was nützt eine scheinbar niedrigere Last auf dem Netzwerk, wenn dafür die CPUs der beteiligten Rechner gequält werden :-

              Comment


              • #8
                Hallo!

                Wir haben jetzt mal Tests mit dem MDAC V2.62 gemacht, und siehe da, es funktioniert gleich viel besser

                Comment

                Working...
                X