From: Thomas Glatthor Date: Fri, 5 Oct 2007 19:10:12 +0000 (+0000) Subject: 80% done X-Git-Tag: Release-3.0.0~2391 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=f6f0556728430ce63492dc23572593910954d65e;p=bacula%2Fdocs 80% done --- diff --git a/docs/manual-de/catmaintenance.tex b/docs/manual-de/catmaintenance.tex index 3b6d47a9..ae3aa572 100644 --- a/docs/manual-de/catmaintenance.tex +++ b/docs/manual-de/catmaintenance.tex @@ -128,7 +128,7 @@ rm -f bacula.sql \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 @@ -172,10 +172,10 @@ Eine typische Ursache von Datenbankproblemen ist das Volllaufen einer Partition. 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 @@ -194,7 +194,7 @@ done \end{verbatim} \normalsize -I invoked it with the following commands: +dieses Shell-Script, wird dann wie folgt aufgerufen: \footnotesize \begin{verbatim} @@ -203,7 +203,8 @@ cd /var/lib/mysql/bacula \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 @@ -211,18 +212,17 @@ rm -f x*.MYD \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} @@ -231,8 +231,8 @@ SHOW TABLE STATUS FROM bacula like "File"; \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} @@ -241,8 +241,8 @@ ALTER TABLE File MAX_ROWS=281474976710656; \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} @@ -250,104 +250,89 @@ set-variable = myisam_data_pointer_size=6 \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} @@ -356,8 +341,8 @@ select * from pg_indexes where tablename='file'; \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} @@ -367,8 +352,10 @@ CREATE INDEX file_fp_idx on file (filenameid, pathid); \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} @@ -377,8 +364,8 @@ show index from File; \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} @@ -388,10 +375,11 @@ CREATE INDEX file_jpf_idx on File (Job, FilenameId, PathId); \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} @@ -401,11 +389,11 @@ show index from Path; \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} @@ -420,7 +408,7 @@ CREATE INDEX Name on Filename (Name(255)); \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} @@ -429,8 +417,7 @@ select * from sqlite_master where type='index' and tbl_name='File'; \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} @@ -443,22 +430,21 @@ CREATE INDEX file_jfp_idx on File (Job, FilenameId, PathId); \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} @@ -468,32 +454,26 @@ rm -f bacula.sql \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} @@ -502,8 +482,7 @@ echo 'vacuum;' | sqlite bacula.db \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} @@ -515,10 +494,9 @@ rm -f bacula.sql \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 }