Beitrag von till (1103 Beiträge) am Mittwoch, 3.September.2003, 15:15.
riesenprobleme mit größerer db
Antworten
Beitrag von Pouraga (1396 Beiträge) am Mittwoch, 3.September.2003, 16:48.
Re: riesenprobleme mit größerer db
Das Problem ist garnichtmal die menge der Eintrage. (Kenne Datenbanken mit über 30.000 Einträgen die funktionieren auch noch)
Aber die Menge an Feldern dazu noch einige Dateien (das Dateihändling frisst Zeit)und textarea Felder lässt die Datenbankgrösse schon explodieren.
Aber trotzdem Baseportal kann das im grunde schon verpacken, aber obwohl Baseportal schneller als andere Datenbank Systeme ist wird eine komplette umorganisation der Datenbank wegen überschreiten der maximalen ausführungszeit vom Server abgebrochen.
Wenn du einen eigenen Server hast kannst du den timout so hoch drehen wie du möchtest. Im zweifel sind dann nur deine Projekte am hängen wenn der Server zu beschäftigt ist.
Vorschläge die dir vielicht jetzt etwas Luft verschaffen:
1. Überprüfe die Felder für die du eine Sortierung gewählt hast, ob du es auch tatsächlich brauchst.
2. Prüfe ob du sinnvoll aus dieser Datenbank Felder in andere Datenbanken verteilen kannst um mit einer relation zu arbeiten.
3. Die wahnsinn mit den 20 Unterkatgorien hätte ich anders gelöst. Indem man eine Datenbank definiert in der diese Unterkategorie Strucktur und Texte ablegt und in dem jeweiligen Datensatz dann nur noch auf die Id der letzten Kategorie verweisst. (oder falls eine abfrage auf alle einträge in dieser und den darunterfolgenden Kategorien nötig ist kann man auch einen ganzen string der enthaltenden Kategorien in richtiger reihenfolge mitspeichern)
Das dürfte die Datenbank um einiges verkleinern, (statt 20 Texte eine Zahl) und macht das verwalten auch einfacher.
Bei der Variante mit dem String muss man dann blos nen eigenes reorg für programmieren, falls man was in der Strucktur ändert (unterkatgorien in andere Hauptkategorien verschiebt etc.)
Die änderungen jetzt aber noch zu machen wo sich die Datenbank schon "festgefahren" hat wird schwierig. Kannst du dich mit umkopier Programmchen nur scheibchenweise durcharbeiten und versuchen dabei den überblick nicht zu verlieren.
Antworten
Beitrag von Tina (259 Beiträge) am Mittwoch, 3.September.2003, 18:33. WWW: ZERGportal.de
Re: riesenprobleme mit größerer db
Jupps, hatte eine Datenbanken mit 100.000 Einträge bei Netdirekt am laufen und ohne irgendwelche Probleme. Heute erzeugt ZERGportal täglich z.b. eine db mit über 20.000 Einträge, die aber dann auch nach 24 Std. wieder gelöscht wird.
Alleine deine 5 Bild-Felder sind schon tödlich wenn du den Schalter "automatisch löschen" gesetzt hast. Wenn du dann z.B. ein Kopie der db löschen willst, müssen zwangläufig alle Bilder mit gelöscht werden und dem Server geht du Puste aus ;-)
Zu dem VTS hatte ich dir deinen Fehler mitgeteilt (get ... get_next) ;-)
Tina
PS: hoffe nur das du nicht derjenige bist, der auch mein Portal ständig lahm legt - alleine im August über 600 mal Code 500 - Interner Server-Fehler - Netdirekt sucht seit gestern den Übeltäter ;-)
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Mittwoch, 3.September.2003, 23:55.
Re: riesenprobleme mit größerer db
Pouraga & Tina habens schon prima erklärt, noch mein Kommentar dazu:
Bestimmte Aktionen erfordern das Durchlaufen aller Datensätze, z.b. Änderungen an der Struktur (Felddefinition) der DB. Ist eine DB entsprechend gross dauert das entsprechend lang (Naturgesetz ;-) ). Auf einem Mietserver, den man sich mit anderen teilt, MUSS eine Beschränkung vorhanden sein, die einzelne Programme abbricht, wenn sie zu lange laufen oder zuviel Speicher belegen. Wenn das passiert können die schlimmsten Dinge entstehen, u.a. Datenverlust.
Auf einem eigenen Server kannst Du treiben was Du willst (wenn die Webserver-Konfiguration so eingestellt ist), dann läuft das Prg. halt ne halbe Stunde oder sogar den halben Tag - andere Zugriffe werden dann entsprechend kaum möglich sein...
Trotzdem kann baseportal auch bei nem Mietaccount Riesen-DBs handlen - wenn man die Struktur nicht nachträglich ändert... Also: Vorher die Definition aufbauen, dann füllen... Wenn die Katze nun schon in den Brunnen gefallen ist, dann wie in
http://baseportal.de/baseportal/baseportal/forum&wcheck=1&Pos=8562.002
beschrieben vorgehen... ;-)
wg. 4.: Ich habe das Beispiel aus der Doku kopiert, auf Deinen DB-Namen angepasst und lief auf Anhieb... ;-)
Antworten
Beitrag von till (1103 Beiträge) am Donnerstag, 4.September.2003, 08:41.
probleme nicht dokumentiert ...wenn man es gewusst hätte
hallo
und erstmal danke für eure tipps & hinweise.
das problem ist folgendes:
nirgendwo, weder in der doku von bp noch in der leistungsbeschreibung von netdirekt ist die rede davon, daß es bei einer db mit mehr als 20 feldern (die die leistungen von bp mal ein wenig ausreizt) zu solchen problemen kommen kann.
dass auf einem server die zeiten geteilt werden müssen ist klar, aber es sollte meiner meinung nach klar und deutlich an alle user die mitteilung gehen, daß in solchen fällen schon kleineste änderungen bei umfangreicheren dbs nicht mehr möglich sind.
um es konkret zu sagen:
das problem ist entstanden, weil ich EINEN EINZIGEN buchstaben in einem optionsfeld ändern wollte. ein schlichter schreibfehler.
es ging - wohlgemerkt - nicht darum dies in allen datensätzen der db zu ändern, sondern NUR in der felddefinition.
daß so etwas nicht möglich ist und einen server in den timeout treibt konnte ich nicht ahnen und schmälert die verwendunsmöglichkeiten von baseportal leider sehr erheblich.
und noch etwas:
daß beim einfügen eines buchstabens in eine feldefiniton HUNDERTE von datensätzen unrettbar verloren gehen (weil die notwendige reorganisation der db durch den server - timout abgebrochen wird) ist katastrophal und nun wirklich nicht mir anzulasten. ohne deutliche und klare hinweise auf diese probleme in einer doku war auch dies nicht zu ahnen.
ich hoffe daß die von netdirekt angekündigte bereiningung dieses bugs (denn ein solcher ist es doch wohl) in bp rasch erfolgt.
daß der kunde jetzt für einen server das ZEHNFACHE pro monat zahlen soll ist schwer (eigentlich gar nicht) zu vermitteln.
till
Antworten
Beitrag von Sander (8133 Beiträge) am Donnerstag, 4.September.2003, 10:15.
Re: probleme nicht dokumentiert ...wenn man es gewusst hätte
Also Till, bei mysql kannst du auf genau die gleichen Probleme stoßen, wenn vom Start weg das datenbankdesign nicht stimmt. dort kann man solche aktionen auch nur ausführen wenn man Zugang per ssh hat. Sobald ein Browser im Spiel ist kann es schiefgehen, weil das Timeout greift. Es ist kein bp-problem sondern ein cgi-Fakt bei hostingangeboten.
Sander
Antworten
Beitrag von till (1103 Beiträge) am Donnerstag, 4.September.2003, 11:13.
schon klar. kunden ping-pong
hi sander,
habe es verstanden.
nur hätte ich niemals erwartet das mini-änderungen solche effekte haben können.
das problem ist:
netdirekt sagt:
der verlust der datensätze ist eien ein bug in baseportal.
----> baseportal it schuld
baseportal sagt:
der server macht timeout
----> netdirekt ist schuld.
das nennt man ping-pong spielen mit kunden.
es wäre niemals passiert, wenn so etwas irgendwo dokumentiert wäre.
im gegenteil wird aber gesagt daß baseportal auch mit größeren datenmengen klarkommt. warum sonst gibt es die angebote mit 100.000 einträgen pro db ?
sind das nebelbomben ?
oder muss man mal vor den mietangeboten deutlich warnen wenn es um professionelle anwendungen geht ?
ich möchte wirklich nicht polemisieren sondern sachlich diskutieren und vor allem eine lösung finden.
aber die aussage von baseportal:
"nimm doch einfach einen eigenen server"
(liegt bei 150 euro pro monat zzgl. der lizenkosten) hilft nicht wirklich weiter.
oder garantiert baseportal dann, daß es 100 % ig zu kenem datenverlust mehr kommt ?
till
Antworten
Beitrag von Sander (8133 Beiträge) am Donnerstag, 4.September.2003, 11:25.
Re: schon klar. kunden ping-pong
nein, du verstehst mich nicht.
netdirekt hat nicht schuld, baseportal genauso wenig.
Nimm php-, perl- oder pythonscripte und dir passiert das selbe, solange sie auf einem Server liegen, der für mehrere Leute da ist. Und nirgends ist es dokumentiert. Es ist ja auch kein Fehler in der Scriptsprache (ok, bei php steht eine Beschreibung, wie man das timeout hochsetzt, wenn man root ist).
auch auf baseportal.de gibts ein timeout, es kann dir hier genauso passieren. Wie lange das script läuft und welche Ressourcen es verbraucht liegt am jeweiligen Hoster.
klar kommt bp mit 100000 DS zurecht, wenn das design stimmt.
Antworten
Beitrag von till (1103 Beiträge) am Donnerstag, 4.September.2003, 12:07.
aussage von netdirekt steht dem entgegen
hallo sander,
du schreibst:
"Wie lange das script läuft und welche Ressourcen es verbraucht liegt am jeweiligen Hoster."
eben nicht. nach aussage von netdirekt ist die beschränkung der script laufzeit bei baseportal in den mietangeboten NICHT vom server sondern von baseportal selber vorgegeben und der datenverlust ist auf den bug in baseportal zurückzuführen.
und auf das timeout im script hat niemand zugriff ! (ausser CB)jedenfalls nicht der beteiber des servers.
oder aber es wird hier seitens netdirekt KÄSE geredet. das kann und möchte ich nicht beurteilen.
till
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Donnerstag, 4.September.2003, 14:30.
Re: aussage von netdirekt steht dem entgegen
Vielleicht nur ein Missverständnis. Ich weiss nicht, wie man eine Laufzeit & Speicherbegrenzung innerhalb des bereits laufenden Skriptes aktiviert & ob das möglich ist oder nicht...
Tatsache ist, dass die Laufzeit- & Speicherbegrenzung vom apache-Webserver durchgeführt wird, die zugehörigen Zeilen in der Konfigurationsdatei (httpd.conf) sehen so aus:
PerlModule Apache::Resource
PerlSetEnv PERL_RLIMIT_CPU 150:150
PerlSetEnv PERL_RLIMIT_AS 35000000:35000000
PerlChildInitHandler Apache::Resource
Damit wird z.b. die Laufzeit auf 150 Sekunden und der Speicher auf 35 MB limitiert...
Antworten
Beitrag von wizard_merlin (32 Beiträge) am Donnerstag, 4.September.2003, 23:38.
Verbesserungsvorschlag ?!
Hallo,
ich kann Till's Ärger verstehen und es ist sicher nicht leicht
dem Kunden gegenüber einen Mehraufwand - ob Zeit oder Geld spielt
dabei keine Rolle - verständlich zu machen. Ich jedenfalls möchte
das Problem nicht am Hals haben und ich denke auch das geht hier
jedem so!
Jedenfalls sollte es für jedes Problem eine passende Lösung geben
die wie folgt aussehen könnte:
Baseportal könnte die notwendige Bearbeitungszeit einer Aktion
im Vorfeld berechnen und mit dem Servertimeout vergleichen. Ist
die errechnete Zeit größer als der Timeout des Servers, so wird
eine Warnung ausgegeben, die auf einen möglichen Datenverlußt
hinweist und als Sicherheit dient.
Ob und wie das machbar ist liegt mir fern, aber ich denke CB wird
hierzu bestimmt Stellung nehmen und hat so etwas vielleicht schon
im Hinterkopf.
wizard_merlin
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Sonntag, 7.September.2003, 01:21.
Re: Verbesserungsvorschlag ?! - schon drin ;-)
Wollte gerade eine entsprechende Warnmeldung einbauen und musste einigermassen überrascht feststellen, dass schon eine drin ist (schon seit 2 Jahren) - das Problem war/ist nur, dass die Grenze ab der die Meldung ausgegeben wurde auf 10 MB DB-Grösse gesetzt war... Anscheinend zu wenig :-((
Habe diese Grenze jetzt auf 1 MB gesetzt, so dass man nun eigentlich auf jeden Fall die Meldung bekommt, wenns nötig ist... Und leider meistens wenns nicht nötig ist, man also gefahrlos Änderungen vornehmen kann. Hoffe das verschreckt dann nich zuviele arglose Nutzer... Naja, fragen dann hoffentlich im Forum nach, bzw. versuchens, nachdem sie ne Sicherheitskopie angelegt haben.....
Antworten
Beitrag von wizard_merlin (32 Beiträge) am Sonntag, 7.September.2003, 10:57.
@ CB - und wie bekomme ich das jetzt in meine Kaufversion?
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Sonntag, 7.September.2003, 20:34.
Re: @ CB - und wie bekomme ich das jetzt in meine Kaufversion?
Naja, _weisst_ Du es denn jetzt nich, dass Du bei grossen DBs nich ohne Sicherheitskopie an der Felddefinition rumschrauben solltest? ;-)
Antworten
Beitrag von wizard_merlin (32 Beiträge) am Sonntag, 7.September.2003, 22:39.
ja schon aber ...........................
soll ich mir jetzt ein eigenes Handbuch mit bp-Verhaltensregeln schreiben???
Versteh mich bitte nicht falsch Christoph, ich kämpfe schon genug mit
dem Zugriff auf die DB's für angemeldete Nutzer, mit dem Zugriff für
unangemeldete Nutzer, mit verschiedenen Templates und individueller Programierung, mit unterschiedlichen Preisangaben und und und...
Ich will nur eines Tages nicht als der große Depp dastehen "falls" ich
es vergessen sollte und eine Änderung stattfinden muss.
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Donnerstag, 4.September.2003, 15:16.
Re: schon klar. kunden ping-pong
> nur hätte ich niemals erwartet das mini-änderungen solche effekte haben können.
manche änderungen sehen zwar mini aus, intern muss aber ne menge getan werden, wie in deinem fall die gesamte DB durchgearbeitet werden...
> netdirekt sagt:
> der verlust der datensätze ist eien ein bug in baseportal.
> ----> baseportal it schuld
ich würde das nicht als "bug" sehen, sondern es ist ein konzeptionelles problem: baseportal läuft als cgi-prozess innerhalb von apache. bei mietangeboten werden diese prozesse in laufzeit & speicher begrenzt, damit nicht einer den kompletten server in beschlag nehmen kann. damit kann das prg. u.u. an einer beliebigen stelle unterbrochen werden, was schwer zu handhaben ist (für jedes prg.) und zu datenverlusten führen kann...
> baseportal sagt:
> der server macht timeout
> ----> netdirekt ist schuld.
von "schuld" hab ich nie gesprochen, ist das falsche wort... mal wieder ein holpriger vergleich: mit ner busfahrkarte kann ich auch keinen klavierflügel transportieren, weil sonst die anderen fahrgäste keinen platz mehr haben. schuld hat da weder der flügelbauer, noch der busfahrer... ;-)
> im gegenteil wird aber gesagt daß baseportal auch mit größeren datenmengen klarkommt. warum sonst gibt es die angebote mit 100.000 einträgen pro db ?
> sind das nebelbomben ?
Es kommt drauf an was man macht. DBs mit >100.000 Einträgen gibt es einige & die funzen auch prima, hier ein Beispiel:
http://baseportal.de/cgi-bin/baseportal.pl?htx=/baseportal/dict_de_en
Da sind 124.413 Einträge und man könnte noch Hundertsde. mehr dazufügen und die Abfrage wäre immer noch genauso schnell... Was man aber z.b. NICHT ohne Weiteres machen kann, ist diese 124 Tsd. Einträge alle durchlaufen und irgendwas damit anstellen, z.b. ALLE Einträge in Grossbuchstaben wandeln - das wird natürlich ne Weile dauern (und wenn es zu lang ist, wird das bei einem Mietangebot vom Server abgebrochen)... Genau das ist aber bei bestimmten Strukturänderungen an der DB nötig - dass alle Datensätze durchlaufen und geändert werden müssen...... Das Ganze erscheint mir selbstverständlich, aber vielleicht unterliege ich hier der Betriebsblindheit.....?
> aber die aussage von baseportal:
> "nimm doch einfach einen eigenen server"
> [...] hilft nicht wirklich weiter.
Das war _ein_ Lösungsvorschlag, eine andere Möglichkeit (die ich hier jetzt schon zum 3. Mal nenne ;-) ) ist eben eine neue DB mit geänderter Struktur anzulegen (bzw. DB kopieren, Inhalt löschen, Felder ändern) und die Daten dort hineinzukopieren, s. http://baseportal.de/baseportal/baseportal/forum&wcheck=1&Pos=8576.1
---
Trotzdem kann baseportal auch bei nem Mietaccount Riesen-DBs handlen - wenn man die Struktur nicht nachträglich ändert... Also: Vorher die Definition aufbauen, dann füllen... Wenn die Katze nun schon in den Brunnen gefallen ist, dann wie in
http://baseportal.de/baseportal/baseportal/forum&wcheck=1&Pos=8562.002
beschrieben vorgehen... ;-)
---
Von anderen kamen inzwischen ja auch einige nützliche Tips zur Vorgehensweise...
> oder garantiert baseportal dann, daß es 100 % ig zu kenem datenverlust mehr kommt ?
Nein, 100% Sicherheit würde ich NIE, NIE, NIE garantieren, das gibts nämlich nicht, nirgendwo ;-)
So, zum Schluss noch: Ich verstehe dass Datenverluste extrem ärgerlich sind und dass das im Prinzip NIE vorkommen dürfte. Oracle ist hier sicher weiter ;-) "Wenn man weiss was man tut", kommt man mit baseportal auch mit grossen DBs wunderbar zurecht, trotzdem sollten Datenverluste nicht vorkommen. Hätte es denn was geholfen, wenn statt der Ausführung der Strukturänderung eine Warnmeldung gekommen wäre: "Sie können diese Aktion nicht ausführen, da sie wahrscheinlich zu lange dauert und u.U. zu Datenverlusten führt" ?
Antworten
Beitrag von Sander (8133 Beiträge) am Donnerstag, 4.September.2003, 18:23.
Re: schon klar. kunden ping-pong
gabs da nicht mal so eine meldung, nachdem sie durch sowas zerstört wurde, das die db auf den alten stand zurückgesetzt wurde?
Antworten
Beitrag von till (1103 Beiträge) am Donnerstag, 4.September.2003, 19:02.
nur ein teil
es stellte sich dann heraus, daß nur ein teil der datensätze gerettet werden konnte.
till
Antworten
Beitrag von till (1103 Beiträge) am Donnerstag, 4.September.2003, 08:46.
@CB: wieder datensätze verschwunden
hallo nochmals,
so langsam verliere ich das vertrauen komplett.
gestern wurden via backup wenigstens einige der datensätze wieder hergestellt (etwa 100).
und eben prüfe ich die db und diese datensätze sind alle wieder verschwunden. das ist bei einer db nun wirklich der GAU.
christoph: wir kommen nicht drum herum miteinander zu telefonieren denke ich.
meine nummer hast du: bitte ruf mich dringend an.
till
Antworten
Beitrag von hempelr (1976 Beiträge) am Donnerstag, 4.September.2003, 12:28.
Re: @CB: wieder datensätze verschwunden
Hallo - sorry - ich muss mich mal kurz einklinken.....
- wenn ne DB einmal "versaut" ist (Strukturänderung bei gefüllter DB, noch dazu auf ein indiziertes Feld) hast du absolut keine Chance mehr, diese sauber zu kriegen, noch dazu wenn die Datenmenge in den Feldern recht gross ist
- Eine Strukturänderung auf ne bestückte DB mit vielen Datensätzen ohne Sicherheitskopie ist eh sträflich, und das nicht nur bei basepoortal, das gilt wohl für alle Datenbanksysteme auch für SQL-DBs auf lokalen Systemen.
Mach mal ne Strukturveränderung bei ner Access-DB auf eine Tabelle mit 10.000 Datensätzen und 25 Feldern unterschiedlichen Indizes und Dateiverknüpfungen - da kannste dir dann das Lachen auch nicht verkneifen.......
- Dein Ärger ist zwar verständlich, aber deine Lernresistenz nicht - es ist doch alles genau erklärt, warum was wie passiert ist.
Das Jammern und Vorwürfe machen hilft wohl eher nicht so richtig weiter, weder dir noch anderen - vielmehr gilt folgendes festzuhalten:
1) KEINE Strukturänderung an dbs ohne vorherige Sicherheitskopie
2) Datenbankdesign ist nicht nebenbei gemacht - vorher genau planen (ist übrigens genau der Punkt, wo sich Hobbyisten von Profis unterscheiden....)
3) Bei Feststellen von Fehlern beim DB-Design komplett neu anfangen - ein Flicken bringt nur Probleme (und btw, auch ein falscher Buchstabe in nem Optionfeld ist ein "versautes" Design - grad bei ner Änderung hier gibts Probleme - für jeden Datensatz mussen die Optionwerte komplett neu in die Datendatei geschrieben werden)
Claus Christmeier hatte mal mit mir vor einiger Zeit, als ich ein ähnliches Prob hatte, telefoniert und mir paar Tipps gegeben - seit ich die beherzigt habe, gibts keine Probs mehr, hier nochmal der wichtigsten:
- wenn neues Feld in bereits mit Daten bestückte DB eingefügt werden soll, immer zunächst ans Ende der DB (Position neu lassen!) - es besteht die Gefahr, dass bei Einfügen in bestehende Struktur ein Fehler auftritt, der erst später zum Tragen kommen kann - dann eine Sicherung - dann ein Reorg, dann Struktur so anpassen, dass Feld an richtiger Stelle steht, dann wieder reorg und dann, wenn alles ok ist mit grosser Wahrscheinlichkeit alles gut gelaufen
- Optionfelder möglichst vermeiden (insbesondere solche mit viel Werten), lieber alles in Textfelder packen und per Perl-Programmscript entsprechend aufbereiten
Ich selbst hatte mal ein ähnliches Problem, nur dass damals die DB viel kleiner war. Aber war halt auch falsch designt und nach ner Strukturänderung dann komplett unbrauchbar, ich konnte machen was ich wollte - die ursprüngliche DB war Müll - blieb nur eins, Sanders Tipp befolgen, neue DB anlegen, anderer Name, Daten, die zu Importieren gingen importieren und seitdem keine solchen Probleme mehr.
Und seit ich i m m e r vor grösseren Änderungen ne Sik anlege, passiert es auch nicht mehr (und regelmässige Sicherung lokal in ein Archiv - das kann dann zur Not auch vom Provider wieder auf dem Server direkt manuell entpackt werden, wenns denn zu gross ist zum Upload) - Murpheys Computergesetze gelten nun mal überall......
Übrigens - ein gesundes Misstrauen seinen selbst gemachten Programm-Scripten gegenüber und redundante Testumgebung zur tatsächlichen "Gebrauchsumgebung§" bei recht komplexen Anwendungen ist m.E. sinnvollerweise aus diesen Gründen angebracht....
Ruben
Antworten
Beitrag von Marc (46 Beiträge) am Donnerstag, 4.September.2003, 09:18.
Re: riesenprobleme mit größerer db
till
ich habe eine hotel-db mit 25.000 sätzen laufen und habe ganz ähnliche erfahrungen gemacht, aber es gibt schon erklärungen:
- wenn du an einer mit xtausend sätzen gefüllten db was änderst (datentypen, sortierung etc.), muss reinidiziert werden und das dauert u.U. ziemlich lange. eigentlich bricht dann nicht der prozess ab, sondern nur die kommunikation mit deinem browser. du siehst das auch daran, dass beim refresh auf die übersichtsseite (wo deine dbs und seiten angezeigt werden) die grösse kontinuierlich wieder steigt. allerdings werden tatsächlich viele sätze gelöscht, keine ahnung warum. das weiss aber vielleicht christoph.
- die Probleme treten m.E. nicht auf, wenn du unindizierte Felder hinzufügst (also ohne Sortierung)
Ich würde deshalb an einer so grossen db keine Strukturänderungen mehr machen, sondern
- eine Kopie der DB erstellen
- den Inhalt der Kopie löschen
- einen Satz einfügen und wieder löschen und dann reorganisieren
- die Struktur in der Kopie umstellen
- die Daten neu in die Kopie laden (entweder via Upload oder mit einer bp-Seite, die per get und put und über eine Begrenzung der range die Daten von einer DB in die andere schaufelt)
- vielleicht noch mal reorganisieren
- und dabei immer die db-grösse im Auge behalten
- und bei allem immer eine Sicherung der Daten auf dem lokalen PC behalten
vielleicht hilfts
marc
Antworten
Beitrag von till (1103 Beiträge) am Freitag, 5.September.2003, 08:50.
jetzt wird es geheimnisvoll
hallo
ich bitte um entschuldigung wenn ich hier das forum nerve, aber es sind neue, sehr seltsame probs mit der erwähnten db aufgetaucht.
wenn ich intern im baseportal bereich mit der eingebauten suchfunktion ein feld auf einen bestimten wert abfrage bekomme ich (z.b.) 12 einträge angezeigt.
manuell sind aber 131 (!) einträge in diesem feld vorhanden.
per externer abfrage erhalte ich wieder alle 131 einträge.
nur halt intern nicht.
das klingt seltsam, ich weiss es. aber es ist tatsache.
ich gehe öffentlich in sack&asche wen nder fehler bei mir liegt, aber ich kann ihn nicht finden.
ach so: die betroffene db hat knapp 16.000 einträge. aber daran soll es wohl nicht liegen denke ich.
hat jemand ideen dazu wieso interne suche und abfrage so extrem verschiedene resultate bringen ? das hat jetzt nichts mehr mot problemen durch änderungen an feldern zu tun. oder ?
till
Antworten
Beitrag von Sander (8133 Beiträge) am Freitag, 5.September.2003, 10:01.
Re: jetzt wird es geheimnisvoll
wie fragst du extern ab?
Sander
Antworten
Beitrag von till (1103 Beiträge) am Freitag, 5.September.2003, 11:35.
Re: jetzt wird es geheimnisvoll
Antworten
Beitrag von Tina (259 Beiträge) am Freitag, 5.September.2003, 10:29. WWW: ZERGportal.de
Re: jetzt wird es geheimnisvoll
Antworten
Beitrag von Monschder (6 Beiträge) am Freitag, 5.September.2003, 11:13.
TIP?
Zwecks den hohen Serverkosten für eigenen Server....
Hast Du vielleicht ein paar Kunden die sich einen Server teilen können?
Dann kannst Du das Timeout hochpumpen und Notfalls den Server etwas mehr belasten...
Antworten
