Aktiviere den Debug-Modus.
Das ist das Ergebnis
Kann damit nichts anfangen.
Könnte sowas passieren, wenn zwei Administratoren gleichzeitg im Backend sind - auch wenn sie nur hineingeschaut, aber nichts verändert haben?
Datenbanksicherung vorhanden?
Wenn ja, einspielen.
Wenn du da auf "Stack Traces" klickst siehst du unter anderem:
mysqli_sql_exception:
Access denied for user 'dbu5505718'@'infongp-de16.clienthosting.eu' (using password: YES)at /homepages/38/d24081757/htdocs/DaCapoLive/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php:285
Handelt es sich um den korrekten user und korrekten Datenbankserver usw. wie in der configuration.php der betroffenen Website hinterlegt?
Ist die Datenbank mit den in der configuration.php hinterlegten Zugangsdaten tatsächlich erreichbar?
Keine Sicherung einspielen. Frag bei IONOS warum die Datenbank gesperrt ist.
Da ist es dann nützlich eine Websitekopie z.B. in einer Subdomain und zweiten Datenbank zu haben auf die man dann die Domain der Website sofort einstellen kann. Wenn der Webhoster "zur Sicherheit "
die Website deaktiviert...
Auch Updates usw. kann man in so einer Websitekopie unproblematisch durchführen oder testen...
Schaut mal per phpmysdmin auf die sessiontabelle.
Habe eine Seite, da läuft diese Tabelle voll.
Muss man dann in phpmyadmin leeren.
Schaut mal per phpmysdmin auf die sessiontabelle.
Habe eine Seite, da läuft diese Tabelle voll.
Muss man dann in phpmyadmin leeren.
Es gibt doch in J5 die "Geplante Aufgabe" mit der Bezeichnung "Sitzungsdatenbereinigung", die standardmäßig einmal täglich läuft und das erledigt.
Gibt es denn auf der Seite eine solche "Hochlastungsanwendung"?
So weit ich sehe, handelt es sich um eine Tanzseite, da wundert mich ein wenig, dass die Datenbank so belastet wurde.
hrybak Moin! Habt ihr schon mal gecheckt, ob eure Site eventuell gehackt wurde? Uns ist das früher mal passiert und dann gab es tatsächlich eine irrsinnig hohe Last, die letztlich durch automatisierten Spamversand entstanden war.
Seit diesem Ereignis (das mich damals zig Stunden Analyse- und Aufräumarbeit gekostet hatte), halte ich meine Installationen stets aktuell und lasse (neben dem täglichen Backup) eine Firewall mitlaufen. Seitdem keine Probleme mehr. 
...oder die Überlastung kommt vom JEvent, nur Vermutungen.
Der Hoster sollte schon Zahlen und Logfiles als Grundlage für die Sperrung bereitstellen.
Einfach mal so eine Aussage in den Raum zu stellen ohne Details ist nicht ok!
Und ja, Jevents ist auch für mich ein heißer Kandidat als Verursacher.
Nutze ich auch bei verschiedenen Seiten und Hoster (NICHT bei Ionos!).
Diesbezüglich noch nie Probleme gehabt.
Ich verstehe die Vermutung zu JEvents auch nicht. Auf 2 Seiten bei Ionos und nie Probleme.
Bei Vermutungen bitte auch den Grund angeben. Das hilft allen.
Leider gibt es von IONOS keine zufriedenstellende Antwort. Die Sperrung soll seitens IONOS automatisch erfolgt sein und der Service kann keine Ursachen benennen. Einfach nur traurig und unprofessionell.
Dennoch einige Erkenntnisse unsererseit:
Der zweite Punkt kann gemäß IONOS auf einen Fehler in MySQL 8.0.38 zurückgeführt werden. Sollte genau diese Version installiert sein, wäre das wohl ein IONOS-Problem. Checken wir gerade.
Zu den verschiedenen Anmerkungen:
Ich verstehe die Vermutung zu JEvents auch nicht.
Die Vereinsverantwortlichen haben es bislang nicht geschafft - trotz stetig wiederholter Aufforderung - abgelaufene, bis zu 10 Jahre alte Events zu löschen. Daher wurde vermutet, dass diese ca. 4000 Events die Ursache der Probleme sein können. Hat sich nach unserem Wissen letztlich aber nicht bestätigt.
Habt ihr schon mal gecheckt, ob eure Site eventuell gehackt wurde?
Wäre möglich, auch wenn die Seite immer uptodate ist, Backups vorhanden sind und Anti-Spam-Komponenten installiert sind.
Gibt es denn auf der Seite eine solche "Hochlastungsanwendung"?
Nichts dergleichen. Darüber hinaus gibt es unsererseits auch keine aktivierten Logging-Aktivitäten und Chats sowieso nicht..
Generell konnten wir bislang noch immer keinen eindeutig nachvollziehbaren Grund für die Sperrung finden. Wir bleiben zwangsläufig dran an der Suche.
