Klamm DB Crash

wenn es da z.B. 1000 Mio Lose gesamt gegeben hat, dann gibt es die jetzt auch!
Und dabei hatte ich mir so viel Mühe gegeben den zeitlichen Ablauf darzustellen wie es dazu kommen kann, dass es eben nicht so ist... Aber birdman hat es ja jetzt nochmal in anderen Worten versucht zu erklären.
 
Und dabei hatte ich mir so viel Mühe gegeben den zeitlichen Ablauf darzustellen wie es dazu kommen kann, dass es eben nicht so ist... Aber birdman hat es ja jetzt nochmal in anderen Worten versucht zu erklären.

Ja, ich weiß was du meinst, evtl sind es dann nicht genau diese 1000 Mio, aber die paar Transaktionen dürften den Kohl nicht fett machen...
 
Ja, ich weiß was du meinst, evtl sind es dann nicht genau diese 1000 Mio, aber die paar Transaktionen dürften den Kohl nicht fett machen...
Allein auf meiner kleinen Seite waren es 2 Transaktionen vor 4:01 Uhr die nicht vom BU erfasst wurden:
03:35:37 15.02.2016
03:54:08 15.02.2016
Also wurde mein EF schon vor 3:35 Uhr gesichert, ich glaube schon dass global gesehen in dieser Zeit einiges an Transaktionen trotz der Uhrzeit gemacht werden.
Und wenn es an manchen Stellen hakt was die Rücküberweisung angeht, weil beide Transaktionspartner sagen, dass sie die Lose nicht haben und deshalb auch nicht einig werden, kommt die Kette der Rückzahlungen ins stocken.
 
Ich hoffe das Sichern von den Lose-Transaktionen Tabellen erfolgt direkt vor/nach dem Sichern der Lose-Kontostände Tabelle. Wenn dazwischen noch massig unwichtiges Zeug gesichert wird existiert massig Inkonsistenzen.
Fall-Beispiel:
- Laufzeit Sicherung Lose-Transaktionen von 03:30Uhr bis 03:35Uhr.
- Laufzeit Sicherung der Lose-Kontostände von 03:55Uhr bis 04:01Uhr.
Hat eine Losetransaktion zwischen 03:36Uhr und 03:54Uhr stattgefunden dann wurden zwar die richtigen Lose-Kontostände gesichert aber die Losetransaktionen fehlen im Backup...


Ist Wartungsmodus überhaupt aktiv wenn Backup erstellt wird? Funktioniert EF-API noch während dem Zeitpunkt?
@Inskin: Siehst du EF Logs mit Rückgabe-Code 1001 von den letzten Tagen die kurz vor 4Uhr(während Backup Time) gemacht wurden?

Gesendet von meinem GT-I9505 mit Tapatalk
 
Zuletzt bearbeitet:
Auch wenn du 5 Backups am Tag hast, ist das Ergebnis (gefühlt) genauso schlimm: Chaos, weil Teile da sind, andere Teile weg sind und man keine Ahnung hat, was wo.
Dann macht man als Seitenbetreiber eben alle 10 Minuten ein Backup, um den Datenverlust zu minimieren. Wenn man schon bei Seiten in dieser Grössenordnung keine transaction-logs hat.

Datenbanken haben für solche "großen" Webseiten wie klamm spezielle Techniken, wo die Platte jeden beliebigen Moment abkacken kann.
Und selbst MySQL kann das, wenn ich das richtig in Erinnerung habe. Welche DB nutzt Klamm denn?

Und ganz ehrlich: Eine Seite mit der Useranzahl, in der es auch nur um Geld geht, kann nicht einfach sagen "Ein Backup pro Tag reicht". Was ist eigentlich mit den Euro-Kontoständen? Sind die auch zurückgesetzt? Was sagen die Prüfer eigentlich dazu, dass von einem ganzen Tag die Date fehlen?
 
@Inskin: Siehst du EF Logs mit Rückgabe-Code 1001 von den letzten Tagen die kurz vor 4Uhr(während Backup Time) gemacht wurden?
Ich logge den Rückgabecode nicht, dennoch kann ich sagen, dass die 2 oben genannten Transaktionen 1001 (=Erfolg) geliefert haben müssen, weil ich logge welche Transaktionen erfolgreich waren und wieviel Lose auf dem EF seien müssten.
Beides deckt sich nur wenn ich die 2 Transaktionen mit einbeziehen. Ich kann also sagen, dass bei mir die nicht mehr angezeigten Transaktionen und der dazu gehörige EF stand passt.
Trotzdem wäre es Lukas Aufgabe hier mal etwas Licht ins dunkle zu bringen. Andere haben sich trotz anderem job damit bis tief in die Nacht beschäftigt.
 
@Marty
Alle 10 min würde hier ja wohl dann die Festplatte sprengen...

Würde mich auch interresieren was da alles zu gehört. Das Forum ja nicht. Sind es wirklich nur die Losesachen?
 
Startseitenvergütung war auf jeden Fall auch dabei, siehst Du, wenn Du in Deinen Kontoauszug guckst.
 
@Marty
Alle 10 min würde hier ja wohl dann die Festplatte sprengen...
Deduplizierung ist hier das Stichwort. Ich kann ein 2 TB SAP-System 10 mal voll sichern und die Sicherung belegt ohne Kompression trotzdem nur knapp 2,1 TB. Nach Kompression dann nur noch knapp 400 GB. Und Deduplizierung kann mittlerweile sogar Windows.
 
Deduplizierung ist hier das Stichwort. Ich kann ein 2 TB SAP-System 10 mal voll sichern und die Sicherung belegt ohne Kompression trotzdem nur knapp 2,1 TB. Nach Kompression dann nur noch knapp 400 GB. Und Deduplizierung kann mittlerweile sogar Windows.

Woraus sich unschwer schließen läßt, daß SAP im Wettbewerb des sinnlosen Plattenplatzverbratens Microsoft ganz dicht auf den Fersen ist. :mrgreen:
 
Dann solltest du das nächste Mal aber nicht einfach nur Wikipedia zitieren, sondern eigene Worte finden.

Den konnte ich mir jetzt nicht verkneifen. ;-)

Datendepli... ähhh.. Datenduplo... ähh also.. wenn Daten da nicht nur 1 mal ääh also zweimal da sind doppelt sozusagen.. also der Platz.. ääh auf der Festplatte.. die in einem Compu.. Pezehh ääh Rechner eingebaut ist.. also wenn dieser Platz doppelt weg ist.. dann kann man diesen Platz wieder reinigen.. quasi mit Besen.. und dan hat man nur noch einen. Also Platz und nicht mehr zwei!
 
Und es ist nicht die Aufgabe der User das alles zusammen zu suchen. Auch nicht die der Seitenbetreiber. Und ich rede hier sicher nicht nur für mich. Auch die oben gemachten psts zeigen das. Der eine 20k der andere 800k, ein Betreiber 25000 k (bei dem ich auch noch 17000k liegen hab). Wo führt das hin?


Die einzigen die es aber noch irgendwie nachvollziehen können sind die Seitenbetreiber


Also heutzutage nennt man sowas Datenbankcrash
früher hies es Losebug/Losegenerierung.

Ich sag es mal offen und erlich mir stinkt die ganze Sache gewaltig.



Was es ihm bringen soll?


Ich habe leider meine Lose gestern getauscht und habe nicht soviel Lose um die Auszahlung von gestern rückzuüberweisen. Und ich werde garantiert nicht mit Verlust zurücktauschen um Lukas Fehler glattzubügeln. Soll er doch Lose generieren und die Miesen der Losebetreiber selber zahlen. Sonst hat er auch keine Probleme mit dem Generieren von Losen

Und das bringt was wenn es NOCH MEHR Lose werden?

Dann hammer alle unsere Lose wieder und vllt mehr und sie sind noch weniger wert^^

Macht was ihr wollt, aber ich sehe das so. Hier wird immer behauptet es ist Lukas Seite, er kann tun und lassen was er will. Tut er ja auch und dann soll er er auch mal dafür zahlen. Nicht immer nur die anderen



s.o.

Ich habe ebenfalls ca.60.000 Lose zuviel am Konto (laut mone)
und ich weis auch wer diese zuwenig hat...

Dann schicke sie demjenigen?



Ich hatte glaub am wenigsten Aufwand - einfach ein Backup vom 15.02.2016, 05:01Uhr eingespielt.:D Es handelt sich um eine reine Leihseite.
Da am 15.02.2016 zwischen 04:01 Uhr(Backup-Time klamm.de) und 05:01Uhr(Backup-Time mein Projekt) keine EF Transaktionen stattgefunden haben, musste ich nichts nachbuchen.


Vllt habe ich ja einen Denkfehler aber laut deiner Aussage hast du ein Backup vom 15.02 um 5.01 genommen weil in der Zeit seit 4.01 keine Transaktionen waren.

Aber was ist mit den Transaktionen von 15.02. 5.01 - ca 13.00 am 16.02 solange fehlen doch alle Daten da zu der Zeit ca das Backup eingespielt wurde?
 
Kurzer Zwischenstand einen Tag nach dem Crash:


- noch offene Lose von ca. 2 Mio Lose
- ca. 10-15 Stunden Arbeit
- etwas über 50 Supporttickets beantwortet
- ca. 50 Forenposts
- einige verärgerte / abgemeldete User, die nicht einsehen, dass ich daran nicht Schuld bin


+ einen Happy Reload Day

:roll:
 
Kurzer Zwischenstand einen Tag nach dem Crash:


- noch offene Lose von ca. 2 Mio Lose
- ca. 10-15 Stunden Arbeit
- etwas über 50 Supporttickets beantwortet
- ca. 50 Forenposts
- einige verärgerte / abgemeldete User, die nicht einsehen, dass ich daran nicht Schuld bin


+ einen Happy Reload Day

:roll:

Alles in allem ein gelungener Klamm tag mit Positiver Bilanz :D