\normalsize
Abh\"{a}gig von der Gr\"{o}{\ss}e Ihrer Datenbank, wird dies mehr oder weniger Zeit und auch Festplattenplatz
-ben\"{o}tigen. Zum Beispiel, wenn ich in das Verzeichnis wechsle, wo meine MySQL-Datenabnk liegt (typischerweise
+ben\"{o}tigen. Zum Beispiel, wenn ich in das Verzeichnis wechsle, wo meine MySQL-Datenbank liegt (typischerweise
/var/lib/mysql) und diese Kommando ausf\"{u}hre:
\footnotesize
In solch einem Fall muss entweder zus\"{a}tzlicher Platz geschaffen werden, oder
belegter Platz freigegeben werden, bevor die Datenbank mit {\bf myisamchk} repariert werden kann.
-Recently my root partition filled and the MySQL database was corrupted.
-Simply running {\bf myisamchk -r} did not fix the problem. However,
-the following script did the trick for me:
+Hier ist ein Beispiel, wie man eine korrupte Datenbank reparieren k\"{o}nnte, falls nach dem Vollaufen
+einer Partition die Datenbankprobleme mit {\bf myisamchk -r} nicht behoben werden k\"{o}nnen:
+kopieren Sie folgende Zeilen in ein Shell-Script names {\bf repair}:
\footnotesize
\begin{verbatim}
#!/bin/sh
\end{verbatim}
\normalsize
-I invoked it with the following commands:
+dieses Shell-Script, wird dann wie folgt aufgerufen:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-Then after ensuring that the database was correctly fixed, I did:
+nachdem sichergestellt ist, dass die Datenbank wieder korrekt funktioniert,
+kann man die alten Datenbank-Dateien l\"{o}schen:
\footnotesize
\begin{verbatim}
cd /var/lib/mysql/bacula
\end{verbatim}
\normalsize
-\section{MySQL Table is Full}
-\index[general]{Database!MySQL Table is Full}
-\index[general]{MySQL Table is Full}
+\section{MySQL-Tabelle ist voll}
+\index[general]{Datenbank!MySQL-Tabelle ist voll}
+\index[general]{MySQL-Tabelle ist voll}
-If you are running into the error {\bf The table 'File' is full ...},
-it is probably because on version 4.x MySQL, the table is limited by
-default to a maximum size of 4 GB and you have probably run into
-the limit. The solution can be found at:
-\elink{http://dev.mysql.com/doc/refman/5.0/en/full-table.html}
-{http://dev.mysql.com/doc/refman/5.0/en/full-table.html}
+Falls ein Fehler wie {\bf The table 'File' is full ...} auftritt,
+passiert das vermutlich, weil bei den MySQL-Versionen 4.x die Tabellengr\"{o}{\ss}e
+standardm\"{a}{\ss}ig auf 4 GB begrenzt ist und Sie dieses Limit erreicht haben.
+Hinweise zu der maximal m\"{o}glichen Tabellengr\"{o}{\ss}e gibt es auf
+\elink{http://dev.mysql.com/doc/refman/5.1/de/table-size.html}{http://dev.mysql.com/doc/refman/5.1/de/table-size.html}
-You can display the maximum length of your table with:
+Sie k\"{o}nnen sich die maximale Tabellengr\"{o}{\ss}e mit:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-If the column labeled "Max\_data\_length" is around 4Gb, this is likely
-to be the source of your problem, and you can modify it with:
+anzeigen lassen. Wenn die Spalte {\bf max\_data\_length} ca. 4 GB entspricht,
+dann ist dass das Problem. Sie k\"{o}nnen die maximale Gr\2{o}{\ss}e mittels:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-Alternatively you can modify your /etc/my.conf file before creating the
-Bacula tables, and in the [mysqld] section set:
+anpassen. Alternativ k\"{o}nnen Sie auch die /etc/my.cnf editieren, bevor Sie die Bacula-Tabellen erstellen,
+setzen Sie im Abschnitt [mysqld]:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-The above myisam data pointer size must be made before you create your
-Bacula tables or it will have no effect.
-The row and pointer size changes should already be the default on MySQL
-version 5.x, so making these changes should only be necessary on MySQL 4.x
-depending on the size of your catalog database.
+Die myisam Data-Pointer-Gr\"{o}{\ss}e muss vor dem anlegen der Bacula-Katalog-Datenbank oder ihrer Tabellen
+gesetzt sein, um wirksam zu sein.
-\section{MySQL Server Has Gone Away}
-\index[general]{Database!MySQL Server Has Gone Away}
-\index[general]{MySQL Server Has Gone Away}
-If you are having problems with the MySQL server disconnecting or with
-messages saying that your MySQL server has gone away, then please read
-the MySQL documentation, which can be found at:
+Die MAX\_ROWS und Pointer-Anpassungen sollten bei MySQL-Versionen > 5.x nicht n\"{o}tig sein,
+somit sind diese \"{A}nderungen nur bei MySQL 4.x, in Abh\"{a}gigkeit von Ihrer Katalog-Datenbank-Gr\"{o}{\ss}e,
+notwendig.
-\elink{http://dev.mysql.com/doc/refman/5.0/en/gone-away.html}
-{http://dev.mysql.com/doc/refman/5.0/en/gone-away.html}
+\section{MySQL-Server Has Gone Away-Fehler}
+\index[general]{Datenbank!MySQL-Server Has Gone Away-Fehler}
+\index[general]{MySQL-Server Has Gone Away-Fehler}
+Fall Sie Probleme damit haben, dass Ihr MySQL-Server nicht mehr erreichbar ist, oder Meldungen wie
+"MySQL server has gone away" erscheinen, dann lesen Sie bitte die MySQL-Dokumentation auf:
+
+\elink{http://dev.mysql.com/doc/refman/5.1/de/gone-away.html}
+{http://dev.mysql.com/doc/refman/5.1/de/gone-away.html}
\label{RepairingPSQL}
-\section{Repairing Your PostgreSQL Database}
-\index[general]{Database!Repairing Your PostgreSQL }
-\index[general]{Repairing Your PostgreSQL Database }
+\section{Reparatur Ihrer PostgreSQL Datenbank}
+\index[general]{Datenbank!Reparatur Ihrer PostgreSQL }
+\index[general]{Reparatur Ihrer PostgreSQL Datenbank}
-The same considerations apply that are indicated above for MySQL. That is,
-consult the PostgreSQL documents for how to repair the database, and also
-consider using Bacula's dbcheck program if the conditions are reasonable for
-using (see above).
+Dieselben \"{U}berlegungen, wie oben f\"{u}r MySQL angef\"{u}hrt, sind auch hier g\"{u}ltig.
+Lesen Sie die PostgreSQL-Dokumentation um zu erfahren, wie Sie Ihre Datenbank reparieren k\"{o}nnen.
+Erw\"{a}gen Sie auch den Einsatz von Bacula's dbcheck-Programm, falls es sinnvoll erscheint (siehe oben).
\label{DatabasePerformance}
-\section{Database Performance Issues}
-\index[general]{Database Performance Issues}
-\index[general]{Performance!Database}
-
-There are a considerable number of ways each of the databases can be
-tuned to improve the performance. Going from an untuned database to one
-that is properly tuned can make a difference of a factor of 100 or more
-in the time to insert or search for records.
-
-For each of the databases, you may get significant improvements by adding
-additional indexes. The comments in the Bacula make\_xxx\_tables give some
-indications as to what indexes may be appropriate. Please see below
-for specific instructions on checking indexes.
-
-For MySQL, what is very important is to use the examine the
-my.cnf file (usually in /etc/my.cnf).
-You may obtain significant performances by switching to
-the my-large.cnf or my-huge.cnf files that come with the MySQL source
-code.
-
-For SQLite3, one significant factor in improving the performance is
-to ensure that there is a "PRAGMA synchronous = NORMAL;" statement.
-This reduces the number of times that the database flushes the in memory
-cache to disk. There are other settings for this PRAGMA that can
-give even further performance improvements at the risk of a database
-corruption if your system crashes.
-
-For PostgreSQL, you might want to consider turning fsync off. Of course
-doing so can cause corrupted databases in the event of a machine crash.
-There are many different ways that you can tune PostgreSQL, the
-following document discusses a few of them:
-\elink{
-http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}
+\section{Datenbank-Leistung}
+\index[general]{Datenbank-Leistung}
+\index[general]{Leistung!Datenbank}
+
+Es gibt viele Wege, die verschiedenen von Bacula unterst\"{u}tzten Datenbanken abzustimmen, um ihre Leistung zu erh\"{o}hen.
+Zwischen einer schlecht und gut abgestimmten Datenbank kann ein Geschwindigkeitsunterschied von 100 und mehr liegen,
+wenn es darum geht Datenbankeintr\"{a}ge zu schreiben oder zu suchen.
+
+Bei jeder der Datenbanken, k\"{o}nnen Sie erhebliche Verbesserungen erwarten, wenn Sie weitere Indexe hinzuf\"{u}gen.
+Die Kommentare in den Bacula make\_xxx\_tables-Scripts (z.B. make\_postgres\_tables) geben einige Hinweise,
+wof\"{u}r Indexe geeignet sind. Sehen Sie bitte auch unten f\"{u}r genaue Informationen, wie Sie Ihre Indexe
+\"{u}berpr\"{u}fen k\"{o}nnen.
+
+F\"{u}r MySQL ist es sehr wichtig, die my.cnf-Datei durchzusehen (gw\"{o}hnlich /etc/my.cnf)
+Eventuell k\"{o}nnen Sie die Leistung wesentlich erh\"{o}hen, wenn Sie die Konfigurationsdateien
+my-large.cnf oder my-huge.cnf aus dem MySQL-Quellcode verwenden.
+
+F\"{u}r SQLite3 ist ein wichtiger Punkt, dass in der Konfiguration die Angabe "PRAGMA synchronous = NORMAL;"
+vorhanden ist. Dadurch werden die Zeitabst\"{a}nde vergr\"{o}{\ss}ert, in denen die Datenbank ihren RAM-Zwischenspeicher
+auf die Festplatte schreibt. Es gibt noch andere Einstellungen f\"{u}r PRAGMA die die Effizienz steigern k\"{o}nnen,
+aber auch das Risiko einer Datenbankbesch\"{a}digung beim Absturz des Systems erh\"{o}hen.
+
+Bei PostgreSQL sollten Sie eventuell in Betracht ziehen "fsync'' abzuschalten,
+aber auch das kann bei Systemabst\"{u}rzen zu Datenbankprobleme f\"{u}hren.
+Es gibt viele Wege die Leistungsf\"{a}higkeit von PostgreSQL zu steigern,
+diese Internetseiten erkl\"{a}ren ein paar von ihnen (auf englisch):
+\elink{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}
{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}.
-There is also a PostgreSQL FAQ question number 3.3 that may
-answer some of your questions about how to improve performance
-of the PostgreSQL engine:
+Auch in den PostgreSQL FAQ's finden sich Hinweise die Performanz zu verbessern:
\elink{
-http://www.postgresql.org/docs/faqs.FAQ.html\#3.3}
-{http://www.postgresql.org/docs/faqs.FAQ.html\#3.3}.
-% TODO: verify above is correct. is this okay for book?
-
-Also for PostgreSQL, look at what "effective\_cache\_size". For a 2GB memory
-machine, you probably want to set it at 131072, but don't set it too high.
-In addition, for a 2GB system, work\_mem = 256000 and
-maintenance\_work\_mem = 256000 seem to be reasonable values. Make
-sure your checkpoint\_segments is set to at least 8.
-
-
-
-\section{Performance Issues Indexes}
-\index[general]{Database Performance Issues Indexes}
-\index[general]{Performance!Database}
-One of the most important considerations for improving performance on
-the Bacula database is to ensure that it has all the appropriate indexes.
-Several users have reported finding that their database did not have
-all the indexes in the default configuration. In addition, you may
-find that because of your own usage patterns, you need additional indexes.
-
-The most important indexes for performance are the three indexes on the
-{\bf File} table. The first index is on {\bf FileId} and is automatically
-made because it is the unique key used to access the table. The other
-two are the JobId index and the (Filename, PathId) index. If these Indexes
-are not present, your performance may suffer a lot.
-
-\subsection{PostgreSQL Indexes}
-On PostgreSQL, you can check to see if you have the proper indexes using
-the following commands:
+http://www.postgresql.org/docs/faqs.FAQ.html#item3.3}
+{http://www.postgresql.org/docs/faqs.FAQ.html#item3.3}.
+
+Bei PostgreSQL sollten Sie auch auf die "effective\_cache\_size" achten.
+F\"{u}r ein System mit 2GB Arbeitsspeicher k\"{o}nnen Sie sie auf 131072 setzen,
+aber setzen Sie sie nicht zu hoch. Zus\"{a}tzlich sind "work_mem = 256000" und
+"maintenance\_work\_mem = 256000", f\"{u}r Systeme mit 2GB Speicher, sinnvolle Werte.
+Stellen Sie sicher das "checkpoint_segments" auf mindestens 8 gesetzt ist.
+
+\section{Datenbank-Leistung und Indexe}
+\index[general]{Datenbank-Leistung und Indexe}
+\index[general]{Leistung!Datenbank und Indexe}
+Eine der wichtigsten Aspekte die Leistungsf\"{a}higkeit der Bacula-Datenbank sicherzustellen ist zu \"{u}berpr\"{u}fen,
+ob alle Indexe richtig sind. Mehrere Benutzer haben angemerkt, dass ihre Datenbank in der Standardkonfiguration
+nicht alle notwendigen Indexe hatte. Auch werden Sie eventuell, abh\"{a}ngig von Ihrem Anwendungszweck,
+zus\"{a}tzlich Indexe ben\"{o}tigen.
+
+Die wichtigsten Indexe f\"{u}r eine schnelle Datenbank sind die drei Indexe auf der {\bf File}-Tabelle.
+Der erste Index ist auf der {\bf FileId} und wird automatisch anglegt, da es der eindeutige Schl\"{u}ssel ist,
+um auf die Tabelle zuzugreifen. Die anderen beiden sind der {\bf JobId}-Index und der {\bf Filename, PathId}-Index.
+Wenn einer dieser Indexe fehlt, verlieret Ihre Datenbank enorm an Performanz.
+
+\subsection{PostgreSQL Indexe}
+Bei PostgreSQL k\"{o}nnen Sie mit dem folgenden Kommandos \"{u}berpr\"{u}fen ob Sie alle Indexe haben:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-If you do not see output that indicates that all three indexes
-are created, you can create the two additional indexes using:
+Wenn Sie keine Ausgaben sehen die anzeigen das alle drei Indexe vorhanden sind,
+k\"{o}nnen Sie die beiden zus\"{a}tzlichen Indexe mit:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
+anlegen.
+
\subsection{MySQL Indexes}
-On MySQL, you can check if you have the proper indexes by:
+Bei MySQL k\"{o}nnen Sie die Indexe mit:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-If the indexes are not present, especially the JobId index, you can
-create them with the following commands:
+\"{u}berpr\"{u}fen.
+Wenn Indexe fehlen, besonders der {\bf JobId}-Index, kann er mit:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-Though normally not a problem, you should ensure that the indexes
-defined for Filename and Path are both set to 255 characters. Some users
-reported performance problems when their indexes were set to 50 characters.
-To check, do:
+erzeugt werden.
+
+Obgleich das normalerweise kein Problem darstellt, sollten Sie sicherstellen, dass Ihre Indexe f\"{u}r {\bf Filename} und {\bf PathId}
+beide auf 255 Zeichen gesetzt sind. Einige Benutzer berichten von Problemem mit Indexen die auf 50 Zeichen gesetzt sind.
+Um das zu kontrollieren, f\"{u}hren Sie:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-and what is important is that for Filename, you have an index with
-Key\_name "Name" and Sub\_part "255". For Pth, you should have a Key\_name
-"Path" and Sub\_part "255". If one or the other does not exist or the
-Sub\_part is less that 255, you can drop and recreate the appropriate
-index with:
+aus.
+F\"{u} die Dateinamen ist es wichtig, dass Sie einen Index haben mit dem Key\_name "Name" und dem Sub\_part "255".
+F\"{u} den Pfad m\"{u}ssen Sie einen Index mit dem Key\_name "Path" und dem Sub\_part "255" haben.
+Wenn einer der Indexe nicht existiert oder der Sub\_part kleiner 255 ist, k\"{o}nnen Sie den Index neu anlegen indem Sie
+die folgende Kommandos benutzen:
\footnotesize
\begin{verbatim}
\subsection{SQLite Indexes}
-On SQLite, you can check if you have the proper indexes by:
+Bei SQLite k\"{o}nnen Sie so die Indexe \"{u}berpr\"{u}fen:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-If the indexes are not present, especially the JobId index, you can
-create them with the following commands:
+Falls ein Index fehlt, im besonderen der {\bf JobId}-Index, k\"{o}nnen Sie ihn mit den folgenden Befehlen erstellen:
\footnotesize
\begin{verbatim}
\label{CompactingPostgres}
-\section{Compacting Your PostgreSQL Database}
-\index[general]{Database!Compacting Your PostgreSQL }
-\index[general]{Compacting Your PostgreSQL Database }
+\section{Komprimieren Ihrer PostgreSQL Datenbank}
+\index[general]{Datenbank!Komprimieren Ihrer PostgreSQL }
+\index[general]{Komprimieren Ihrer PostgreSQL Datenbank }
-Over time, as noted above, your database will tend to grow. I've noticed that
-even though Bacula regularly prunes files, PostgreSQL has a {\bf VACUUM}
-command that will compact your database for you. Alternatively you may want to
-use the {\bf vacuumdb} command, which can be run from a cron job.
+\"{U}ber die Zeit, wie schon oben angemerkt, wird Ihre Datenbank wachsen.
+Auch wenn Bacula regelm\"{a}{\ss}ig alte Daten l\"{o}scht, wird das PostgreSQL Kommando {\bf VACUUM}
+Ihnen helfen die Datenbank zu komprimieren. Alternativ wollen Sie eventuell das {\bf vacuumdb}-Kommande nutzen,
+das vom cron-Dienst gestartet werden kann.
-All database programs have some means of writing the database out in ASCII
-format and then reloading it. Doing so will re-create the database from
-scratch producing a compacted result, so below, we show you how you can do
-this for PostgreSQL.
+Alle Datenbanken haben Hilfsmittel, um die Daten in eine ASCII-Datei zu schreiben um sie dann erneut einzulesen.
+Wenn Sie das tun, wird die Datenbank komplett neu aufgebaut und so eine kompaktere Version entstehen.
+Wie Sie so etwas tun k\"{o}nnen, zeigt Ihnen das folgende PostgreSQL Beispiel.
-For a {\bf PostgreSQL} database, you could write the Bacula database as an
-ASCII file (bacula.sql) then reload it by doing the following:
+Bei einer PostgreSQL-Datenbank lassen Sie die Daten in eine ASCII-Datei schreiben und neu einlesen,
+wenn Sie diese Kommandos ausf\"{u}hren:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-Depending on the size of your database, this will take more or less time and a
-fair amount of disk space. For example, you can {\bf cd} to the location of
-the Bacula database (typically /usr/local/pgsql/data or possible
-/var/lib/pgsql/data) and check the size.
-
-There are certain PostgreSQL users who do not recommend the above
-procedure. They have the following to say:
-PostgreSQL does not
-need to be dumped/restored to keep the database efficient. A normal
-process of vacuuming will prevent the database from every getting too
-large. If you want to fine-tweak the database storage, commands such
-as VACUUM FULL, REINDEX, and CLUSTER exist specifically to keep you
-from having to do a dump/restore.
-
-Finally, you might want to look at the PostgreSQL documentation on
-this subject at
-\elink{http://www.postgresql.org/docs/8.1/interactive/maintenance.html}
-{http://www.postgresql.org/docs/8.1/interactive/maintenance.html}.
-
-\section{Compacting Your SQLite Database}
-\index[general]{Compacting Your SQLite Database }
-\index[general]{Database!Compacting Your SQLite }
-
-First please read the previous section that explains why it is necessary to
-compress a database. SQLite version 2.8.4 and greater have the {\bf Vacuum}
-command for compacting the database.
+Abh\"{a}gig von Ihrer Datenabnkgr\"{o}{\ss}e wird dieser Vorgang mehr oder weniger Zeit und Festplattenplatz in anspruch nehmen.
+Sie sollten vorher in das Arbeitsverzeichnis Ihrer Datenbank wechseln (typischerweise /var/lib/postgres/data) und die Gr\"{o}[\ss}e \"{u}berpr\"{u}fen.
+
+Bestimmte PostgreSQL-Nutzer empfehlen nicht die oben genannte Prozedur, sie sind der Meinung:
+bei PostgreSQL ist es nicht notwendig, die Daten zu exportieren um sie dann wieder einzulesen.
+Das normale Ausf\"{u}hren des {\bf VACUUM}-Kommandos reicht, um die Datenbank performant zu halten.
+Wenn Sie es ganz genau machen wollen, benutzen Sie speziellen Kommandos {\bf VACUUM FULL, REINDEX} und {\bf CLUSTER}
+um sich den Umweg \"{u}ber das exportiren und wiedereinlesen der Daten zu ersparen.
+
+Zum Schlu{\ss} wollen Sie vielleicht noch einen Blick auf die zugeh\"{o}rige PostgreSQL-Dokumentation werfen,
+Sie finden sie (auf englisch) unter:
+\elink{http://www.postgresql.org/docs/8.2/interactive/maintenance.html}
+{http://www.postgresql.org/docs/8.2/interactive/maintenance.html}.
+
+\section{Komprimieren Ihrer SQLite Datenbank}
+\index[general]{Komprimieren Ihrer SQLite Datenbank}
+\index[general]{Datenbank!Komprimieren Ihrer SQLite }
+
+Lesen Sie bitte zuerst die vorherigen Abschnitte die erkl\"{a}ren, warum es erforderlich ist, eine Datenbank zu komprimieren.
+SQLite-Versionen gr\"{o}{\ss}er 2.8.4 haben das {\bf Vacuum}-Kommando um die Datenbank zu komprimieren:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-As an alternative, you can use the following commands, adapted to your system:
-
+Als Alternative k\"{o}nnen Sie auch die folgenden Kommandos (auf Ihr System angepasst) benutzen:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-Where {\bf working-directory} is the directory that you specified in the
-Director's configuration file. Note, in the case of SQLite, it is necessary to
-completely delete (rm) the old database before creating a new compressed
-version.
+Wobei {\bf working-directory} das Verzeichnis ist, dass Sie in Ihrer Director-Dienst-Konfiguration angegeben haben.
+Beachten Sie bitte, dass es im Fall von SQLite erforderlich ist, die alte Datenbank komplett zu l\"{o}schen,
+bevor die komprimierte Version angelegt werden kann.
\section{Migrating from SQLite to MySQL}
\index[general]{MySQL!Migrating from SQLite to }
projects / bacula / docs / commitdiff