SQL Suche benimmt sich eigenartig

  • Hallo!


    Eigentlich ist die SQL Suche extrem flott, selbst wenn man das gesamte Archiv seit dem Jahr 2000 mit-durchsucht.

    Aber seit einiger Zeit sucht er unendlich lange und findet bei manchen Suchen am Ende einfach "nichts", bei anderen Suchbegriffen funktioniert es wie immer.


    Wenn ich die Suche begrenze, also die Suche in Unterordern abschalte, dann findet er sehr schnell die richtigen Ergebnisse.

    Irgendwo ist hier der Wurm drin und wir wissen nicht wo.

    Die Datenbank neu indizieren haben wir auch schon gemacht.


    Hat irgendwer Ideen dazu?

    Gruß,

    Thorsten

  • Hi,


    gibt es im David Ereignisse Ordner Meldung zum SQL Server?

    Wie groß ist die Datenbank?

    https://ihr-it.support
    Bietet seit zwanzig Jahren Systemhaus Lösungen für kleine bis mittlere Kunden an.
    Auf meiner Homepage finden Sie Infos zu allen Zertifizierungen und Partnerschaften ;)
    Support Hotline: 07345 23 63 80

  • Ah ja....einige Fehler....meint er damit RAM oder Platten-Platz?

    Die Datenbank hat 78GB. Vollwertiger SQL Server. Die Platte hat noch 160GB frei...




    SQL Error 8007000e
    Code 8007000e
    Code meaning F³r diesen Vorgang ist nicht gen³gend Speicher verf³gbar.
    Source (null)
    Description
    Function m_srParam[]->Value
    Command Filling Stored Procedure Params: fn: i0273119, arcID: 509397
    User ID ffffffff
  • Nope ich denke hier geht es um die Größe der DB, die kannst du über das SQL Management Studio anpassen.

    https://ihr-it.support
    Bietet seit zwanzig Jahren Systemhaus Lösungen für kleine bis mittlere Kunden an.
    Auf meiner Homepage finden Sie Infos zu allen Zertifizierungen und Partnerschaften ;)
    Support Hotline: 07345 23 63 80

  • Hallo, ich muss das Thema nochmal aufwärmen - die SQL Suche ist sehr langsam.

    VMware ESX 4.1.0

    Bisher versucht:

    Hardware RAM auf 192 GB erweitert

    Server läuft jetzt mit Windows 2008R2 Enterprise / 64 GB zugeteilt

    SQL Server 2008 R2 Standard

    Volume für David & SQL 993 GB / 81 frei

    David Archive DB 95 GB / 20 frei


    Nach der Aufrüstung wurde die Datenbank zurück gesetzt und die Indexierung neu gestartet.


    Während der Indexierung war das SL 2 mal nicht erreichbar.


    Das äußert sich in dem die User das Login Fenster sehen und sollen Name und Passwort eintragen. In den Diensten ist das SL gestartet. Während dessen kommen auch die SQL-Fehler 8007000e wieder.


    Nach Beenden des SL und erneutem Start ist der Zugriff wieder möglich. Auch die Indexierung läuft wieder los und hat per heute rund 8,7 Mio Nachrichten indexiert. Eigentlich sollte alles laufen.


    Trotzdem ist die SQL Suche in vielen Fällen extrem langsam und hatte allein heute rund 20 Timeouts.


    SQL Error 80040e31

    Code 80040e31

    Code meaning IDispatch error #3121

    Source Microsoft OLE DB Provider for SQL Server

    Description Abfragetimeout abgelaufen

    Function m_rs->Open

    Hat vielleicht jemand eine Idee dazu?

  • Ich bin WGmemphis im gleichen Unternehmen. Egal was ich suche, er sucht "unendlich" und bricht irgendwann ohne Ergebnis ab (TimeOut im Protokoll). Nur wenn ich in einem einzelnen Ordner ohne Unterordner suche, dann findet er was, auch wenn er dafür ebenso einige Sekunden braucht.

    Wiederhole ich die Suche, wird es auch nicht schneller. Ich hätte erwartet, dass dazwischen ein schneller Cache sitzt.


    Will heißen: Die SQL Suche an sich funktioniert, sucht aber extrem viel zu langsam, so dass der SQL Server nach 2 Minuten mit Timeout abbricht.


    Da ist echt der Wurm drin

  • Läuft auf der SQL Server Instanz nur die Datenbank von David oder auch eine andere?

    Gibt es Auffälligkeiten in den SQL Server Protokollen?

    Wie viel RAM darf / benutzt der SQL Server?

    https://ihr-it.support
    Bietet seit zwanzig Jahren Systemhaus Lösungen für kleine bis mittlere Kunden an.
    Auf meiner Homepage finden Sie Infos zu allen Zertifizierungen und Partnerschaften ;)
    Support Hotline: 07345 23 63 80

  • Hallo Stylistics,


    auf dem SQL Server läuft nur die David Datenbank.

    Die SQL Protokolldatei sieht harmlos aus, siehe unten als eingefügte Grafik. David und SQL sind auf gleichem VMware Server mit Zuteilung von 64GB RAM. Diese haben wir gerade erst vor einer Woche von 32GB hochgerüstet, weil wir dachten, das wäre der Grund für die Langsamkeit.


    CPU Last am Server heute aktuell um 30%, also auch alles gut.


    Aber nun halte Dich fest:

    Gestern habe ich mehrere Versuche gemacht, alles mit dem gleichen Suchbegriff, mal über "alles", mal über einzelne Ordner-Zweige, mal nur über Einzelordner. Erst bei Einzelordnern kam ein Ergebnis, beim Rest wurden die genannten SQL Timeouts von David protokolliert. Deshalb hat mein Kollege WGMemphis gestern abend den Eintrag hier im Forum geposted.


    Heute 11.50 Uhr mache ich die GLEICHE Abfrage wie gestern, also mit dem gleichen Suchbegriff, wieder zunächst über ALLE Ordner (also rund 400GB zu durchsuchen) und ich erhalte nach 5 Sekunden ein Ergebnis!


    Was ist heute anders als gestern? Das Problem tritt immer wieder auf, ist also kein Einzelfall.

    Vielleicht zwingt irgendetwas manchmal die CPU in die Knie?

    Wir werden - sobald das Problem wieder da ist - die CPU Last prüfen.


    Für weitere Ideen sind wir natürlich dankbar!

    Gruß,

    Thorsten


  • Man kann die SQL Suche schön in die Enge treiben.

    Ein Kunde von uns signiert seine Mails immer mit Br Dmitrii

    Lasse ich die SQL Suche mit Anführungszeichen nach "Br Dmitrii" suchen, findet er.

    Suche ich aber nach "Br Dmitr*" , dann sucht er unendlich bis zum Timeout.


    Ich vermute fast, dass der David das Suchkommando an den SQL Server übergibt und nach einer gewissen Zeit den Timeout meldet, aber dabei "nicht immer" auch die SQL Suche wirklich abstoppt. So führen erneute Suchanfragen dann zum Aufstapeln mehrerer Suchjobs, die den SQL Server machmal für etliche Minuten in die Knie zwingen. Das würde erklären, warum unser SQL manchmal unendlich langsam wird.


    Leider konnte ich das bisher nicht nachstellen. Wenn ich die Suche nach "Br Dmitr*" gestartet habe (die unendlich läuft, weil SQL wahrscheinlich mit diesem Suchbegriff in irgendeine Endlosschleife läuft) und dann einen neuen Suchbegriff eingebe, dann findet er wieder schnell. Offenbar hat er also die vorherige Suche doch abgebrochen, oder sie läuft zwar noch, aber es liegen noch nicht so viele Suchjobs auf dem Stapel, dass er wieder langsam wird.

  • Wir kriegen unsere SQL Such Probleme nicht los....echt hartnäckig.

    Selbst ein Tobit-Partner, dem wir von dem Problem berichtet haben, schreibt uns nur wir sollen am besten Tobit involvieren. Naja, Tobit hat keinen Außendienst und schaltet sich auch eher selten auf Kundensysteme auf, oder?

    Hat noch jemand einen Tipp?

  • Vielleicht hilft das Stichtwort SQL STOP Wörter. Bin mir da nicht sicher. Also es gibt eine Reihe von Buchstabenkombinationen, die einfach vom SQL Server nicht indiziert werden. Diese Liste kann man irgendwo im SQL Server auch einsehen, hab es aber leider im Moment nicht mehr im Kopf wo.

    ***** Tobit Partner *****

  • Hm,


    wir haben immer mal wieder Probleme mit SQL-Datenbanken und der Suche. Ein SQL-Spezialist schaut sich das dann an und optimiert den Index für diese Art der Anfrage. Und dann rennt das System.


    Das Problem tritt meist dann auf, wenn der Programmierer etwas Neues reingeschoben hat.


    Das ist jetzt keine konkrete Lösung, aber ein Erfahrungsbericht. Das Festlegen von Stopp-Wörtern kann sicher auch helfen. Aber ggfs. sollte man sich so einen Experten einmal leisten.


    BigDaddy911

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!