Re: Umgebungsvariablen
Hallo! Am Don, 2003-02-20 um 17.03 schrieb Raphael Mack: > Hallo, > > wo muss ich denn Umgebungsvariablen, die ich für ALLE Benutzer gesetzt haben > will setzen? Bei meinem Linux Mandrake ging das in der /etc/profile. Wenn ich > hier in debian was rein schreibe hat das für mich keine sichtbaren > Auswirkungen - zumindest unter X. Habe es gerade noch getestet, die Änderungen > haben schon ihre Wirkung. Aber nur, wenn ich mich nicht-grafisch auf tty > einlogge. > An was liegt das? > > Danke, > Rapha Gestern abend hier (es läuft woody) entdeckt: /etc/bash.bashrc - Umgebungsvariablen hier setzen wirkt systemweit unter X. ~/bashrc - entsprechend für einen Nutzer. /etc/profile - Hier werden die auf der Konsole eingestellt. ~/bash_profile - Dito, nutzerbezogen. Hat jemand eine Erklärung, welchen Zweck diese Konstruktion hat? Ich fänd' es ja sinnvoller, alle Einstellungen jeweils in einer Datei machen zu können... Gruss Peter -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: [OT]Re: Backup von einer postgreSQL mit 80 GByte?
Hallo, Michelle! Am Die, 2003-02-04 um 12.18 schrieb Michelle Konzack: [...] > Habe gerade noch mal in meinem Buch nachspioniert... > Bist Du sicher, das es NOTIFY und LISTEN bei postgresql gibt ? > > Ich finde im ganzen (O'Reilly)Buch nichts darueber. Schau mal in der HTML-Doku nach, unter SQL-Commands. (Ausserdem habe ich es im PostgreSQL-Buch von Jens Hartwig gefunden - Addison-Wesley 2001, ISBN 3-8273-1860-2) [...] > > Die Frage ist nun, brauche ich bei einem Backup wirklich soviele > Kopfstaende oder habe ich da was uebersehen ??? > > Derzeit arbeite ich mit c- und php-cgi's die die arbeit machen, aber > kann ich sowas auch mit postgresql machen ? Unter M$-Access habe ich > halt macros programmiert aber ich habe noch so gewisse Probleme mit > postgresql... Warum an der Datenbank herumbauen, wenn sie funktioniert? Kann aus der Ferne nicht einschätzen, was gefährlicher ist: Die Skripte ändern oder die Datenbank... Vermute, es beträfe die Datenbank... [...] Gruss Peter -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: kann vfat (fat32) filesystem nicht user-writable mounten -trotz anleitung
Hallo! Am Fre, 2003-02-07 um 10.27 schrieb Jens Schuessler: > * Peter Jenke <[EMAIL PROTECTED]> [07-02-03 09:16]: > > Der Eintrag 'defaults' überschreibt m.W. die nachfolgenden Optionen. > > Nein, das ist genau andersrum, die nachfolgenden Optionen überschreiben > die defaults. > /dev/hda1 /mnt/C vfat defaults,ro,user,noexec,uid=1000,gid=1000 > > defaults ist rw, mounte ich das Dateisystem so bekomme ich readonly. Ist natürlich richtig - sorry für den Schnellschuss... Gruss Peter -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: kann vfat (fat32) filesystem nicht user-writable mounten -trotz anleitung
Hallo! On Thu, 2003-02-06 at 18:48, [EMAIL PROTECTED] wrote: [...] > > der eintrag in /etc/fstab lautet: > /dev/hda1 /test vfat defaults,user,noauto,uid=1001,gid=100 0 0 > > aus /etc/passwd: > eva:x:1001:100::/home/eva:/bin/bash > > aus /etc/group: > users:x:100:knoppix,eva > > vor dem mounten liefert ls -l / : > drwxr-xr-x2 eva users4096 Feb 6 11:41 test > > nach dem mounten: > drwxr--r--8 root root 8192 Jan 1 1970 test > > obwohl es nach den anleitungen eva:users zugeordnet sollte! [...] Der Eintrag 'defaults' überschreibt m.W. die nachfolgenden Optionen. Hier sieht das so aus: /dev/hda1 /win_c vfatuid=root,gid=winuser,umask=007 0 0 Gruss Peter -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: [OT]Re: Backup von einer postgreSQL mit 80 GByte?
Hallo, Marc! Am Son, 2003-02-02 um 15.24 schrieb Marc F. Neininger: > Am Fre, 2003-01-31 um 01.39 schrieb Michelle Konzack: > Hallo Michelle, > hallo Liste, > > > Hmmm, ich denke, das _modifiziert_ sofort beim auslesen geleert > > werden muss, denn wenn ich danach mit pg_dump die liste abarbeite, > > rennt die postgresql ja weiter und weitere Tabellen koennten > > modifiziert werden. > > Das Backup-Konzept wirkt langsam ziemlich clever. Ich gebe nur zu > bedenken, dass laut Murphy genau _nach_ dem Leeren von _modifiziert_ > Dein Computer hängenbleiben wird. Also würde ich _modifiziert_ nicht > leeren, sondern umbenennen und für neue Einträge neu anlegen. Dann > kannst Du pg_dump in aller Ruhe auf das alte _modifiziert_ loslassen. [...] Wenn das Skript, dass _modifiziert_ ausliest, abgearbeitet ist, sollten die Daten in einer Datei stehen. Erst dann kann die Tabelle geleert werden. Sollte die Kiste beim Auslesen abstürzen, geht's nach dem Neustart mit der unveränderten Tabelle von vorn los (Fall 1); nach dem Auslesen sind die Daten in der Datei fixiert, dann interessiert der Tabelleninhalt für diese Sicherung nicht mehr (Fall 2). Sollte Michelle vermeiden, dass im zweiten Fall u.U. neue Einträge in die Tabelle gelangen, bevor sie gelöscht wird? Na ja: Eine Tabelle, die vor dem Absturz modifiziert wurde, würde nochmal gesichert. Wenn sie nach dem Absturz nicht mehr verändert wird, kommt sie nochmal ins Backup, was nicht schadet, sondern nur Platz wegnimmt. Wird sie verändert, vermerkt das Skript sie ohnehin als zu sichernd. Das heisst: Nach 'nem Absturz kann sie so bleiben, wie sie ist - Leeren erst bei der nächsten Sicherung. Hab' ich was übersehen? Mir scheint, als ob eine Tabelle reicht. Noch 'ne Bemerkung zur Cleverness: Ich halte das Verfahren für ziemlich umständlich. Besser wär's, stattdessen mit Funktionen zu arbeiten (das kann PostgreSQL). Es gibt ausserdem in PostgreSQL die Möglichkeit, Ereignisse mit NOTIFY und LISTEN zu überwachen (wenn die Tabelle xyz verändert wird, bekommt der LISTENER automatisch eine Nachricht). Und schliesslich bietet PostgreSQL Transaktionen an - damit lassen sich die Eventualitäten beim Rechnerbetrieb ganz gut regulieren. Ich denke, dass PostgreSQL so zu betreiben ist, dass auch das Backup vom Datenbanksystem selbst erledigt wird. Aber: Die Datenbank läuft bei Michelle schon; ob es möglich ist, sie so umzubauen, dass der Workaround nicht gebraucht wird, kann ich nicht beurteilen, deswegen habe ich nichts anderes vorgeschlagen. (Nicht als Rüffel verstehen, Marc!) Gruss Peter -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: [OT]Re: Backup von einer postgreSQL mit 80 GByte?
Hallo, Michelle, Am Fre, 2003-01-31 um 02.39 schrieb Michelle Konzack: [...] > Hmmm, ich denke, das _modifiziert_ sofort beim auslesen geleert > werden muss, denn wenn ich danach mit pg_dump die liste abarbeite, > rennt die postgresql ja weiter und weitere Tabellen koennten > modifiziert werden. Klar. > > >Apropos Verwaltungskram: Der fällt weg, wenn Du die Datenbank mit > >pg_dump sicherst. Es könnte sein, dass Dein Backup kleiner ausfällt als > >die 80GB. Wär' vielleicht einen Versuch wert.(Ich habe hier eine > >Datenbank, die auf dem Rechner etwas über 100MB belegt - keine > >Optimierung gemacht, Indizees sind nicht angelegt - die Nutzdaten sind > >ungefähr 15MB gross.) > > Richtig, aber ich kann eben nicht jeden Tag ein Master-Backup machen, > sondern warscheinlich nur einmal im Monat (wenn ich nach paris fahre), > denn selbst 80->12 GByte per Internet Backupen ist nicht drin. > > Da braucht man selbst bei einer E1 mindestens 20 Stunden bei voller last. > > >Zu Deiner anderen Mail: > >Die komplette Datenbank solltest Du mit pg_dump bzw. pg_dumpall sichern. > >(Vielleicht hast Du ja Glück und alles passt auf eine CD... s.o.) > > Sind mit pg_dumpall rund 39 GByte... > Das passt noch nicht einmal auf DVD's. Schade... Wechselplatte? (Ob die Datenbank aus einzelnen Tabellendumps zu restaurieren ist, kann ich nicht beurteilen - das hängt ja davon ab, wie sie organisiert ist.) [...] Gruss Peter -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
[OT]Re: Backup von einer postgreSQL mit 80 GByte?
Hallo, Michelle, On Tue, 21 Jan 2003 18:17:06 +0200 Michelle Konzack <[EMAIL PROTECTED]> wrote: [...] > Die Frage ist, wie soll ich die zusaetzliche Tabelle vernuenftig > anlegen ? > > Einfach zwei Spalten (Tabelle + 0|1-Flag) ??? > [...] Entschuldige bitte die verzögerte Antwort: Ich bin ein paar Tage nicht an meine Mails gekommen. Zur Tabelle für die Tabellennamen: Du willst für eine inkrementelle Datensicherung den Überblick behalten, welche Tabellen innerhalb eines bestimmten Zeitraums verändert wurden. Dafür reicht es aus, die Tabellennamen zu kennen, also genügt eine Tabelle mit einer einzigen Spalte, sagen wir, die heisst _modifiziert_. Anlegen mit psql: CREATE TABLE _modifiziert_ ( tab_name VARCHAR(40) NOT NULL ); Wenn Du willst, kannst Du dir noch einen Zeitstempel eintragen lassen, ich glaube, das geht mit TIMESTAMP - hab' ich aber noch nicht probiert. Ein extra Flag ist nicht nötig, denn in der Tabelle sind nur modifizierte Tabellen verzeichnet: Bei jeder Aktion, die Inhalte in der Datenbank verändern, den Tabellennamen speichern mitINSERT INTO _modifiziert_ ( tab_name ) VALUES ( $tabellenname ); Für die Sicherung die Namen aus der Tabelle auslesen mit SELECT DISTINCT * FROM _modifiziert_; Das DISTINCT bewirkt, das mehrfache Einträge nur einmal im Ergebnis erscheinen. Ich würde die Ausgabe in eine Datei schreiben und mit dieser Datei ein Skript füttern, dass die Tabellen mit pg_dump (siehe meine erste Mail) sichert. Nach dem Backup muss _modifiziert_ wieder leer sein: DELETE FROM _modifiziert_; löscht alle Einträge. Tabellen mit OID? Als binäres Objekt??? Warum? Interessant ist am Ende doch nur, was in der Tabelle drinsteht und nicht der Verwaltungskram drumrum, den Du dann mitschleppen musst... Apropos Verwaltungskram: Der fällt weg, wenn Du die Datenbank mit pg_dump sicherst. Es könnte sein, dass Dein Backup kleiner ausfällt als die 80GB. Wär' vielleicht einen Versuch wert.(Ich habe hier eine Datenbank, die auf dem Rechner etwas über 100MB belegt - keine Optimierung gemacht, Indizees sind nicht angelegt - die Nutzdaten sind ungefähr 15MB gross.) Zu Deiner anderen Mail: Die komplette Datenbank solltest Du mit pg_dump bzw. pg_dumpall sichern. (Vielleicht hast Du ja Glück und alles passt auf eine CD... s.o.) Mir fällt noch ein: Falls in der Datenbank viel gelöscht wird, musst Du Dir mal VACUUM ansehen. PostgreSQL löscht Daten nicht unmittelbar, sondern markiert sie nur als gelöscht. Mit VACUUM kriegst Du sie wohl los. (Hab' ich aber auch nur nachgelesen, noch nicht probiert...) Gruss Peter -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Backup von einer postgreSQL mit 80 GByte?
hallo! noch ein nachtrag zu meiner mail von gestern: die information, ob eine tabelle verändert wurde oder nicht, solltest du nicht in der tabelle selbst speichern - dann müsstest du ja alle ca. 800 000 tabellen abklappern, um zu erfahren, welche gesichert werden müssen. praktischer wäre es, glaube ich, eine extra tabelle dafür anzulegen, in die die name veränderter tabellen eingetragen werden. das backup-skript könnte dann die namen per select holen und an pg_dump übergeben. irgendwann (beim eintragen in die tabelle oder im skript) müsstest du nur noch mehrfache einträge löschen, damit jede tabelle nur einmal gesichert wird. gruss peter -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Backup von einer postgreSQL mit 80 GByte?
hallo! On Thu, 09 Jan 2003 14:41:18 + Michelle Konzack <[EMAIL PROTECTED]> wrote: [...] > >> Dachte, man sollte ein script machen, das die einzelnen 830.000 > >> Tabellen als Textdateien exportiert und gziped. > > > >Hm, aber doch nicht _jede_ Table einzeln ;-) > > Was spricht dagegen ? > mueste dann allerdings meine php4-Scripte und CGI's anpassen, > das es eine zusaetzliche columne einfuegt (1|0) damit das > backup-script erkennt, welche tabellen geaendert worden sind... > ...und nur Tabellen in denen eine '1' steht werden ins > incremental-Backup aufgenommen. Ich denke, das die groeste > Tabelle (so 30 Stueck) rund 15 MByte hat, und die Restlichen > 79 GByte auf die restlichen Tabellen verzeilt werden. immerhin > so rund 100 kByte pro Tabelle. und bei rund 200-400 neuen > Tabellen pro Tag ein ertraegliches mass an updates... [...] ich habe hier gerade ausprobiert: pg_dump -d -t _tabelle_ _datenbank_ > _tabelle_.dmp der parameter -t bringt pg_dump dazu, eine einzelne tabelle aus der datenbank _datenbank_ zu exportieren. gruss peter -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
