Syn-Flood Fehler bei mehrfachem SELECT & UPDATE

  • VB.NET

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Syn-Flood Fehler bei mehrfachem SELECT & UPDATE

    Hallo liebe Community,

    ich habe ein Problem wo ich im Moment nicht weiter komme :(. Durch mehrere Select- und Update Abfragen auf eine Mysql Datenbank in einer Schleife (ca. 500 mal) wird der MySQL Port gesperrt. Bei weniger Schleifendurchgängen bekomme ich diese Fehlermeldung nicht.
    Mein Antivirusprogramm zeigt mir im Protokoll an, dass mein Programm ein Merkmal für ein Syn-Flood enthält und sperrt den Port deshalb. Wahrscheinlich wegen der vielen Anfragen in Abhängigkeit von der Zeit. Ich möchte ungern mein Programm verlangsamen durch z.B. Sleepings. Lokal funktioniert es mit den Sleepings,über das Netzwerk wir es eng. Abgesehen davon bin ich kein Fan von thread.Sleep :!: .


    Mit freundlichen Grüßen


    ga_wital
    warum so oft? sag uns was du laden willst (bzw. warum so oft) und wir können dir dass mit dem verknüpfen sinnvoll erklären...

    weil generell bekommst du auch eine 500-fache abfrage in eine abfrage rein, des weiteren hört es sich so an als wäre es immer die selbe... dann kannste auch objekte klonen und hast nur einen run zur db.

    runs zur db (vor allem so viele in so kurzer zeit) machen dir das netzwerk dicht. und alles in allemfehleranfälliger.

    Quellcode

    1. dbdoneabfr = clODBC.GetDataTable("SELECT xyz from auftrag WHERE Auftrag =" & int_ übergnr, False)



    "int_übergnr" ändert sich je nach Schleifendurchlauf. Die Datenbank wird einmal, am anfang, im Programmablauf geöffnet und am ende geschlossen, d.h. es kann nicht zu masigem öffnen und schließen kommen.



    Quellcode

    1. clODBC.SetQuery("UPDATE auftrag SET xyz = ';Keine PLZ vergeben;' where auftrag = " & int_übergnr & "", False)



    Das Update wird je nachdem angeschubst, wenn z.B. PLZ nicht vergeben ist.


    EDIT

    Subselects sind nicht möglich da ich gebunden bin mit der 3.51 mysql zu entwickeln und subselects anscheinend erst ab 4.0 möglich sind.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ga_wital“ ()

    Zum einen stört mich dass sowohl Tabelle als auch Spalte "auftrag" heißt.
    Aber das nur am Rande.

    Wenn die Tabelle nicht allzu umfangreich ist, kannst du vielleicht auch

    SQL-Abfrage

    1. SELECT auftrag, xyz FROM auftrag
    verwenden und die Daten lokal auswerten.

    Oder gleich intelligent abfragen.
    Du willst nur Auftragsnummern, bei denen xyz nicht vorhanden ist?

    SQL-Abfrage

    1. SELECT auftrag FROM auftrag WHERE xyz IS NULL


    Oder automatisch updaten:

    SQL-Abfrage

    1. "UPDATE auftrag SET xyz = ';Keine PLZ vergeben;' WHERE PLZ is NULL
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --
    In welchem Zahlenbereich läuft deine Schleife? Oder holst du dir vorher schon alle übergeordneten Gruppennummern aus der Datenbank?
    Dient das Programm z.B. nur dazu um in der Datenbank zu ermitteln, bei welchem Auftrag keine PLZ vorhanden ist?

    Eventuell könnte man hier mit einer "Stored Procedure" (gespeicherten Prozedure/Routine) arbeiten.
    D.h. die Arbeit wird direkt am Datenbankserver ausgeführt und du stößt diese nur über ein Tool/Programm an.
    Für MySQL gibt es ne NET .dll.
    Mit der kannst du (performanter) als über ODBC arbeiten.
    Außerdem kannst du darüber sehr entspannt die Tabellen, die du bearbeiten willst, in ein typisiertes DataSet laden.
    Diese kannst du dann "offline" beackern und dann zurückschreiben.
    Das ist meine Signatur und sie wird wunderbar sein!
    Vermutlich wäre es ein einfaches

    SQL-Abfrage

    1. SELECT * FROM TableName


    In eine DGV oder DT, was auch immer (EDR kann dass am besten ^^ (zumindest besser als ich)

    Mit dem Objekt verarbeitest du die Werte (da dann die ganze Tabelle mit ihren Datensätzen drinne steht

    Und dann am Ende

    SQL-Abfrage

    1. UPDATE TableName
    oder so ähnlich, das Objekt dass du Anfangs erhalten hast gibst du wieder an die DB (Via Programmcode) und die DB macht den Rest automatisch. Je nachdem wie es genau aussieht ließe sich dies dann auf zwei!!! SQL´s reduzieren.

    icemanns schrieb:

    In welchem Zahlenbereich läuft deine Schleife? Oder holst du dir vorher schon alle übergeordneten Gruppennummern aus der Datenbank?
    Dient das Programm z.B. nur dazu um in der Datenbank zu ermitteln, bei welchem Auftrag keine PLZ vorhanden ist?

    Eventuell könnte man hier mit einer "Stored Procedure" (gespeicherten Prozedure/Routine) arbeiten.
    D.h. die Arbeit wird direkt am Datenbankserver ausgeführt und du stößt diese nur über ein Tool/Programm an.
    Die Schleife läuft im Moment 500 mal durch, wie oben benannt. Am Datenbankserver direkt zu werken, wollte ich eig. vermeiden.

    ErfinderDesRades schrieb:

    wie berechnen sich denn die 500 verschiedenen Werte von "int_übergnr"?

    evtl. lässt sich das auch ins Sql packen
    die 500 werte werden aus einer datei ausgelesen ,die vorhanden ist, un in ein array geschrieben.
    Lade dir doch einfach alles (die tabelle) in ein DataSet odeer ähnliches, damit kannst du effektiever daran arbeiten, es geht um ein vielfaches schneller als deine Methode und vor allem hast du keine unglaubliche Netzwerkauslastung. Ich habe mit meinen durch UnitTests bedingten und nicht vermeidbaren Datenbank-Zugriffen schon einen hohen Overhead, wie soll dass aussehen wenn es der normalfall ist? Wer würde so ein Programm wollen? Es ist nicht nur Arschlahm, sondern eben die Datenbank wird gefloodet, sperrt evtl und vor allem dass Netzwerk, welches ja benötigt wird in Firmen, wird gefloodet. Überdenk doch erstmal die Ansätze die geliefert wurden und halte nicht an dem fertigen, welcher wie du sioehst nicht läuft, fest. Sondern überdenke dass ganze mal...

    ga_wital schrieb:

    die 500 werte werden aus einer datei ausgelesen ,die vorhanden ist, un in ein array geschrieben.

    dassisja komisch, dass die in einer Datei sind, statt in der Datenbank.

    weiles handelt sich doch um Auftrag-IDs.
    Möglicherweise wäre performant, die via DataAdapter erstmal in die DB einzuspeisen, und dann könnteman die entsprechenden Aufträge mit einem InnerJoin-Select abrufen.