From: Thomas Glatthor Date: Fri, 12 Oct 2007 13:04:45 +0000 (+0000) Subject: translated X-Git-Tag: Release-3.0.0~2383 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=087e309f9ea33543728f1c000f08f935bbbe7477;p=bacula%2Fdocs translated --- diff --git a/docs/manual-de/catmaintenance.tex b/docs/manual-de/catmaintenance.tex index ae3aa572..27d3cedf 100644 --- a/docs/manual-de/catmaintenance.tex +++ b/docs/manual-de/catmaintenance.tex @@ -52,13 +52,13 @@ des Director-Dienstes benutzt um alte Katalog-Eintr\"{a}ge zu l\"{o}schen. Da die Datei-Eintr\"{a}ge ca. 80 Prozent der Katalog-Datenbankgr\"{o}{\ss}e ausmachen, sollten Sie sorgf\"{a}lltig ermitteln \"{u}ber welchen Zeitraum Sie die Eintr\"{a}ge aufbewahren wollen. -Nachdem die Datei-Eintr\"{a}ge ge\"{o}scht wurden, ist es nicht mehr m\"{o}glich einzelne dieser Dateien +Nachdem die Datei-Eintr\"{a}ge gel\"{o}scht wurden, ist es nicht mehr m\"{o}glich einzelne dieser Dateien mit einem R\"{u}cksicherungs-Job wiederherzustellen, aber die Bacula-Versionen 1.37 und sp\"{a}ter sind in der Lage, aufgrund des Job-Eintrags im Katalog, alle Dateien des Jobs zur\"{u}ckzusichern solange der Job-Eintrag im Katalog vorhanden ist. Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch -eine Nummer von Hilfsangaben vorhanden, so dass man Minuten, Stunden, Tage, Wochen, +eine Reihe von Hilfsangaben m\"{o}glich, so dass man Minuten, Stunden, Tage, Wochen, Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time} dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren. @@ -70,7 +70,7 @@ Der Standardwert der Aufbewahrungszeit f\"{u}r Dateien ist 60 Tage. Job-Eintr\"{a}ge in der Katalog-Datenbank aufbewahrt werden. Wenn {\bf AutoPrune} in der Client-Konfiguration auf {\bf yes} gesetzt ist, wird Bacula die Katalog-Eintr\"{a}ge der Jobs l\"{o}schen, die \"{a}lter als -dieser Zeitraum sind. Beachten Sie, dass wenn ein Job-Eintrag ge\"{o}scht wird, +dieser Zeitraum sind. Beachten Sie, dass wenn ein Job-Eintrag gel\"{o}scht wird, auch alle zu diesem Job geh\"{o}renden Datei- und JobMedia-Eintr\"{a}ge aus dem Katalog gel\"{o}scht werden. Dies passiert unabh\"{a}ngig von der Aufbewahrungszeit f\"{u}r Dateien, infolge dessen wird die Aufbewahrungszeit f\"{u}r Dateien normalerweise k\"{u}rzer sein als f\"{u}r Jobs. @@ -78,11 +78,11 @@ infolge dessen wird die Aufbewahrungszeit f\"{u}r Dateien normalerweise k\"{u}rz Wie oben erw\"{a}hnt, sind Sie nicht mehr in der Lage einzelne Dateien eines Jobs zur\"{u}ckzusichern, wenn die Datei-Eintr\"{a}ge aus der Katalog-Datenbank entfernt wurden. Jedoch, solange der Job-Eintrag im Katalog vorhanden ist, k\"{o}nnen Sie immer noch den kompletten Job mit allen Dateien wiederherstellen -(mit Bacula-Version 1.37 und gr\"{o}{\ss}er). Daher ist es eine gute Idee, die Job-Eintr\"{a}ge im Katalog +(ab Bacula-Version 1.37 und gr\"{o}{\ss}er). Daher ist es eine gute Idee, die Job-Eintr\"{a}ge im Katalog l\"{a}nger als die Datei-Eintr\"{a}ge aufzubewahren. Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch -eine Nummer von Hilfsangaben vorhanden, so dass man Minuten, Stunden, Tage, Wochen, +eine Reihe von Hilfsangaben m\"{o}glich, so dass man Minuten, Stunden, Tage, Wochen, Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time} dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren. @@ -127,9 +127,9 @@ rm -f bacula.sql \end{verbatim} \normalsize -Abh\"{a}gig von der Gr\"{o}{\ss}e Ihrer Datenbank, wird dies mehr oder weniger Zeit und auch Festplattenplatz +Abh\"{a}ngig 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-Datenbank liegt (typischerweise -/var/lib/mysql) und diese Kommando ausf\"{u}hre: +/var/lib/mysql) und dieses Kommando ausf\"{u}hre: \footnotesize \begin{verbatim} @@ -140,8 +140,8 @@ du bacula bekomme ich die Ausgabe {\bf 620,644}, was bedeutet dass das Verzeichnis bacula 620.644 Bl\"{o}cke von 1024 Bytes auf der Festplatte belegt, meine Datenbank enth\"{a}lt also ca. 635 MB an Daten. Nachdem ich das {\bf mysqldump} ausgef\"{u}hrt habe, ist die dabei entstandene Datei bacula.sql -{\bf 174.356} Bl\"{o}cke gro{\ss}, wenn diese Datei wieder mit dem Kommando {\bf mysql bacula < bacula.sql} -in die Datenbank importiert wird, ergibt sich eine Datenbankgr\"{o}{\ss}e von nur noch {\bf 210.464} +{\bf 174.356} Bl\"{o}cke gro{\ss}, wenn diese Datei mit dem Kommando {\bf mysql bacula \< bacula.sql} +wieder in die Datenbank importiert wird, ergibt sich eine Datenbankgr\"{o}{\ss}e von nur noch {\bf 210.464} Bl\"{o}cken. Mit anderen Worten, die komprimierte Version meiner Datenbank, die seit ca. 1 Jahr in Benutzung ist, ist ungef\"{a}hr nur noch ein Drittel so gro{\ss} wie vorher. @@ -157,7 +157,7 @@ Als Konsequenz wird empfohlen, auf die Gr\"{o}{\ss}e der Datenbank zu achten und Wenn Sie bemerken, dass das Schreiben der MySQL-Datenbank zu Fehlern f\"{u}hrt, oder das der Director-Dienst h\"{a}ngt, wenn er auf die Datenbank zugreift, sollten Sie sich die MySQL Datenbank\"{u}berpr\"{u}fungs- und Reparaturprogramme ansehen. -Welches Programm Sie laufen lassen sollten, h\"{a}ngt von der von Ihnen benutzten Datenbank- +Welches Programm Sie laufen lassen sollten, h\"{a}ngt mit der von Ihnen benutzten Datenbank- Indizierung zusammen. Wenn Sie das Standardverfahren nutzen, werden Sie vermutlich {\bf myisamchk} laufen lassen. F\"{a}r n\"{a}here Information lesen Sie bitte auch: \elink{http://dev.mysql.com/doc/refman/5.1/de/client-utility-programs.html} @@ -232,7 +232,7 @@ SHOW TABLE STATUS FROM bacula like "File"; \normalsize 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: +dann ist dass das Problem. Sie k\"{o}nnen die maximale Gr\"{o}{\ss}e aber mit: \footnotesize \begin{verbatim} @@ -251,10 +251,10 @@ set-variable = myisam_data_pointer_size=6 \normalsize -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. +Die myisam Data-Pointer-Gr\"{o}{\ss}e muss vor dem Anlegen der Bacula-Katalog-Datenbank oder ihrer Tabellen +gesetzt werden, um wirksam zu sein. -Die MAX\_ROWS und Pointer-Anpassungen sollten bei MySQL-Versionen > 5.x nicht n\"{o}tig sein, +Die MAX\_ROWS und Pointer-Anpassungen sollten bei MySQL-Versionen gr\"{o}{\ss}er 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. @@ -498,59 +498,58 @@ Wobei {\bf working-directory} das Verzeichnis ist, dass Sie in Ihrer Director-Di 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 } -\index[general]{Migrating from SQLite to MySQL } +\section{Migration von SQLite zu MySQL} +\index[general]{MySQL!Migration von SQLite zu } +\index[general]{Migration von SQLite zu MySQL } -You may begin using Bacula with SQLite then later find that you want to switch -to MySQL for any of a number of reasons: SQLite tends to use more disk than -MySQL; when the database is corrupted it is often more catastrophic than -with MySQL or PostgreSQL. -Several users have succeeded in converting from SQLite to MySQL by -exporting the MySQL data and then processing it with Perl scripts -prior to putting it into MySQL. This is, however, not a simple -process. +Wenn Sie Bacula anfangs mit SQLite zusammen benutzt haben, gibt es sp\"{a}ter +eine Reihe von Gr\"{u}nden, weshalb Sie eventuell auf MySQL umsteigen wollen: +SQLite belegt mehr Festplattenplatz f\"{u}r dieselbe Datenmenge als MySQL; +falls die Datenbank besch\"{a}digt wird, ist es mit SQLite problematischer als +bei MySQL oder PostgreSQL, sie wiederherzustellen. Viele Benutzer sind erfolgreich +von SQLite auf MySQL umgestiegen, indem sie zuerst die Daten exportiert haben und sie dann +mit einem z.B. Perl-Script in ein passendes Format konvertiert haben, um sie in die +MySQL-Datenbank zu importieren. Dies ist aber kein sehr einfacher Vorgang. \label{BackingUpBacula} -\section{Backing Up Your Bacula Database} -\index[general]{Backing Up Your Bacula Database } -\index[general]{Database!Backing Up Your Bacula } - -If ever the machine on which your Bacula database crashes, and you need to -restore from backup tapes, one of your first priorities will probably be to -recover the database. Although Bacula will happily backup your catalog -database if it is specified in the FileSet, this is not a very good way to do -it, because the database will be saved while Bacula is modifying it. Thus the -database may be in an instable state. Worse yet, you will backup the database -before all the Bacula updates have been applied. - -To resolve these problems, you need to backup the database after all the backup -jobs have been run. In addition, you will want to make a copy while Bacula is -not modifying it. To do so, you can use two scripts provided in the release -{\bf make\_catalog\_backup} and {\bf delete\_catalog\_backup}. These files -will be automatically generated along with all the other Bacula scripts. The -first script will make an ASCII copy of your Bacula database into {\bf -bacula.sql} in the working directory you specified in your configuration, and -the second will delete the {\bf bacula.sql} file. - -The basic sequence of events to make this work correctly is as follows: +\section{Sichern Ihrer Bacula Datenbank} +\index[general]{Sichern Ihrer Bacula Datenbank} +\index[general]{Datenbank!Sichern Ihrer Bacula } + +Falls jemals der Rechner auf dem Ihre Bacula-Installation l\"{a}uft abst\"{u}rzt, +und Sie diesen wiederherstellen m\"{u}ssen, wird es einer der ersten Schritte sein, +die Datenbank zur\"{u}ckzusichern. Obwohl Bacula fr\"{o}hlich die Datenbank sichert, +wenn sie im FileSet angegeben ist, ist das kein sehr guter Weg, da Bacula die Datenbank +\"{a}ndert, w\"{a}hrend sie gesichert wird. Dadurch ist die gesicherte Datenbank wahrscheinlich +in einem inkonsistenten Zustand. Noch schlimmer ist, dass die Datenbank gesichert wird, +bevor Bacula alle Aktualisierungen durchf\"{u}hren kann. + +Um diese Problem zu umgehen, m\"{u}ssen Sie die Datenbank sichern nachdem alle Backup-Jobs +gelaufen sind. Zus\"{a}tzlich werden Sie wohl eine Kopie der Datenbank erstellen wollen, +w\"{a}hrend Bacula keine Aktualisierungen vornimmt. Um das zu erreichen, k\"{o}nnen Sie +die beiden Scripte {\bf make\_catalog\_backup} und {\bf delete\_catalog\_backup} benutzen, +die Ihrer Bacula-Version beiliegen. Diese Dateien werden, zusammen mit den anderen Bacula-Scripts, +automatisch erzeugt. Das erste Script erzeugt eine ASCII-Kopie Ihrer Datenbank namens {\bf bacula.sql} +in dem Arbeitsverzeichnis, dass Sie in der Konfiguration angegeben haben. Das zweite Script +l\"{o}scht die Datei {\bf bacula.sql} wieder. + +Die grundlegenden Arbeitsschritte damit alles korrekt funktioniert, sind folgende: \begin{itemize} -\item Run all your nightly backups -\item After running your nightly backups, run a Catalog backup Job -\item The Catalog backup job must be scheduled after your last nightly backup +\item alle Backup-Jobs laufen lassen +\item wenn alle Jobs beendet sind, wird ein Catalog Backup-Job gestartet +\item Der Catalog Backup-Job muss nach den anderen Backup-Jobs laufen -\item You use {\bf RunBeforeJob} to create the ASCII backup file and {\bf - RunAfterJob} to clean up +\item Benutzen Sie {\bf RunBeforeJob} um die ASCII-Sicherungsdatei zu erstellen und + {\bf RunAfterJob} um sie wieder zu l\"{o}schen \end{itemize} -Assuming that you start all your nightly backup jobs at 1:05 am (and that they -run one after another), you can do the catalog backup with the following -additional Director configuration statements: +Angenommen Sie starten alle Ihre Backup-Jobs nachts um 01:05, k\"{o}nnen Sie das Catalog-Backup +mit der folgenden zus\"{a}tzlichen Director-Dienst-Konfiguration ausf\"{u}hren lassen: \footnotesize \begin{verbatim} -# Backup the catalog database (after the nightly save) +# Catalog-Datenbank-Backup (nach der n\"{a}chtlichen Sicherung) Job { Name = "BackupCatalog" Type = Backup @@ -564,12 +563,12 @@ Job { RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup" Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr" } -# This schedule does the catalog. It starts after the WeeklyCycle +# Diese Schedule starten das Catalog-Backup nach den anderen Sicherungen Schedule { Name = "WeeklyCycleAfterBackup Run = Level=Full sun-sat at 1:10 } -# This is the backup of the catalog +# Das FileSet f\"{u}r die ASCII-Kopie der Datenbank FileSet { Name = "Catalog" Include { @@ -582,95 +581,89 @@ FileSet { \end{verbatim} \normalsize -Be sure to write a bootstrap file as in the above example. However, it is preferable -to write or copy the bootstrap file to another computer. It will allow -you to quickly recover the database backup should that be necessary. If -you do not have a bootstrap file, it is still possible to recover your -database backup, but it will be more work and take longer. +Stellen Sie sicher, dass, wie in dem Beispiel, eine Bootstrap-Datei geschrieben wird. +Bevorzugterweise wird eine Kopie dieser Bootstrap-Datei auf einem andern Computer gespeichert. +Dies erlaubt eine schnelle Wiederherstellung der Datenbank, falls erforderlich. Wenn Sie +keine Bootstrap-Datei haben, ist es trotzdem m\"{o}glich, erfordert aber mehr Arbeit und dauert l\"{a}nger. \label{BackingUPOtherDBs} -\section{Backing Up Third Party Databases} -\index[general]{Backing Up Third Party Databases } -\index[general]{Databases!Backing Up Third Party } - -If you are running a database in production mode on your machine, Bacula will -happily backup the files, but if the database is in use while Bacula is -reading it, you may back it up in an unstable state. - -The best solution is to shutdown your database before backing it up, or use -some tool specific to your database to make a valid live copy perhaps by -dumping the database in ASCII format. I am not a database expert, so I cannot -provide you advice on how to do this, but if you are unsure about how to -backup your database, you might try visiting the Backup Central site, which -has been renamed Storage Mountain (www.backupcentral.com). In particular, -their -\elink{ Free Backup and Recovery -Software}{http://www.backupcentral.com/toc-free-backup-software.html} page has -links to scripts that show you how to shutdown and backup most major -databases. +\section{Sicherung anderer Datenbanken} +\index[general]{Sicherung anderer Datenbanken } +\index[general]{Datenbanken!Sicherung anderer } + +Wie oben schon erw\"{a}hnt wurde, f\"{u}hrt das Sichern von Datenbank-Dateien im laufenden Betrieb +dazu, dass die gesicherten Dateien sich wahrscheinlich in einem inkonsistenten Zustand befinden. + +Die beste L\"{o}sung daf\"{u}r ist, die Datenbank vor der Sicherung zu stoppen, +oder datenbankspezifische Hilfsprogramme zu verwenden, um eine g\"{u}ltige Sicherungsdatei zu erstellen, +die Bacula dann auf die Volumes schreiben kann. Wenn Sie unsicher sind, wie Sie das am besten mit der +von Ihnen benutzten Datenbank erreichen k\"{o}nnen, hilft Ihnen eventuell die Webseite von Backup Central +weiter. Auf \elink{ Free Backup and Recovery Software}{http://www.backupcentral.com/toc-free-backup-software.html} +finden Sie Links zu Scripts die zeigen, wie man die meisten gr\"{o}{\ss}eren Datenbanken sichern kann. + \label{Size} -\section{Database Size} -\index[general]{Size!Database } -\index[general]{Database Size } +\section{Datenbank Gr\"{o}{\ss}e} +\index[general]{Gr\"{o}{\ss}e!Datenbank } +\index[general]{Datenbank Gr\"{o}{\ss}e } -As mentioned above, if you do not do automatic pruning, your Catalog will grow -each time you run a Job. Normally, you should decide how long you want File -records to be maintained in the Catalog and set the {\bf File Retention} -period to that time. Then you can either wait and see how big your Catalog -gets or make a calculation assuming approximately 154 bytes for each File -saved and knowing the number of Files that are saved during each backup and -the number of Clients you backup. +Wenn Sie nicht automatisch alte Datens\"{a}tze aus Ihrer Katalog-Datenbank l\"{o}schen lassen, +wird Ihre Datenbank mit jedem gelaufenen Backup-Job wachsen (siehe auch weiter oben). +Normalerweise sollten Sie sich entscheiden, wie lange Sie die Datei-Eintr\"{a}ge im Katalog +aufbewaren wollen und die {\bf File Retention} entsprechend konfigurieren. Dann k\"{o}nnen Sie +entweder abwarten wie gro{\ss} Ihre Katalog-Datenbank werden wird, oder es aber auch unge\"{a}hr +berechnen. Dazu m\"{u}ssen Sie wissen, dass f\"{u}r jede gesicherte Datei in etwa 154 Bytes in der +Katalog-Datenbank belegt werden und wieviele Dateien Sie auf wievielen Computern sichern werden. -For example, suppose you do a backup of two systems, each with 100,000 files. -Suppose further that you do a Full backup weekly and an Incremental every day, -and that the Incremental backup typically saves 4,000 files. The size of your -database after a month can roughly be calculated as: +Ein Beispiel: angenommen Sie sichern zwei Computer, jeder mit 100.000 Dateien. +Weiterhin angenommen, Sie machen ein w\"{o}chentliches Full-Backup und ein +inkrementelles jeden Tag, wobei bei einem inkrementellen Backup typischerweise 4.000 Dateien +gesichert werden. Die ungef\"{a}hre Gr\"{o}{\ss}e Ihrer Datenbank nach einem Monat +kann dann so berechnet werden: \footnotesize \begin{verbatim} - Size = 154 * No. Systems * (100,000 * 4 + 10,000 * 26) + Gr\"{o}{\ss}e = 154 * Anzahl Computer * (100.000 * 4 + 10.000 * 26) \end{verbatim} \normalsize -where we have assumed four weeks in a month and 26 incremental backups per month. -This would give the following: - +wenn ein Monat mit 4 Wochen angenommen wird, werden also 26 inkrementelle Backups im Monat laufen. +Das ergibt das folgende: \footnotesize \begin{verbatim} - Size = 154 * 2 * (100,000 * 4 + 10,000 * 26) + Gr\"{o}{\ss}e = 154 * 2 * (100.000 * 4 + 10.000 * 26) or - Size = 308 * (400,000 + 260,000) + Gr\"{o}{\ss}e = 308 * (400.000 + 260.000) or - Size = 203,280,000 bytes + Gr\"{o}{\ss}e = 203.280.000 Bytes \end{verbatim} \normalsize -So for the above two systems, we should expect to have a database size of -approximately 200 Megabytes. Of course, this will vary according to how many -files are actually backed up. - -Below are some statistics for a MySQL database containing Job records for five -Clients beginning September 2001 through May 2002 (8.5 months) and File -records for the last 80 days. (Older File records have been pruned). For these -systems, only the user files and system files that change are backed up. The -core part of the system is assumed to be easily reloaded from the Red Hat rpms. +f\"{u}r die beiden oben angenommen Computer k\"{o}nnen wir also davon ausgehen, dass die Datenbank +in etwa 200 Megabytes gro{\ss} wird. Nat\"{u}rlich h\"{a}ngt dieser Wert davon ab, wieviele +Dateien wirklich gesichert werden. +Unten sehen Sie ein paar Statistiken f\"{u}r eine MySQL-Datenbank die Job-Eintr\"{a}ge +f\"{u}r 5 Clients \{u}ber 8.5 Monate und Datei-Eintr\"{a}ge \"{u}ber 80 Tage enth\"{a}lt +(\"{a}ltere Datei-Eintr\"{a}ge wurden schon gel\"{o}scht). Bei diesen 5 Clients wurden nur +die Benutzer- und System-Dateien gesichert, die sich st\"{a}ndig \"{a}ndern. Bei allen +anderen Dateien wird angenommen, dass sie leicht aus den Software-Paketen des Betriebssystems +wiederherstellbar sind. -In the list below, the files (corresponding to Bacula Tables) with the -extension .MYD contain the data records whereas files with the extension .MYI -contain indexes. +In der Liste sind die Dateien (die den MySQL-Tabellen entsprechen) mit der Endung .MYD +die, die die eigentlichen Daten enthalten und die mit der Endung .MYI enthalten die Indexe. -You will note that the File records (containing the file attributes) make up -the large bulk of the number of records as well as the space used (459 Mega -Bytes including the indexes). As a consequence, the most important Retention -period will be the {\bf File Retention} period. A quick calculation shows that -for each File that is saved, the database grows by approximately 150 bytes. +Sie werden bemerken, dass die meisten Eintr\"{a}ge in der Datei File.MYD +(die die Datei-Attribute enth\"{a}lt) enthalten sind und diese auch den +meisten Platz auf der Festplatte belegt. Die {\bf File Retention} (der Aufbewahrungszeitraum +f\"{u}r Dateien) ist also im wesentlichen daf\"{u}r verantwortlich, wie gro{\ss} die Datenbank wird. +Eine kurze Berechnung zeigt, dass die Datenbank mit jeder gesicherten Datei ungef\"{a}hr um +154 Bytes w\"{a}chst. \footnotesize \begin{verbatim} - Size in - Bytes Records File +Gr\"{o}{\ss}e + in Bytes Eintr\"{a}ge Dateiname ============ ========= =========== 168 5 Client.MYD 3,072 Client.MYI @@ -695,13 +688,14 @@ for each File that is saved, the database grows by approximately 150 bytes. \end{verbatim} \normalsize -This database has a total size of approximately 450 Megabytes. +Die Datenbank hat eine Gr\"{o}{\ss}e von ca. 450 Megabytes.. -If we were using SQLite, the determination of the total database size would be -much easier since it is a single file, but we would have less insight to the -size of the individual tables as we have in this case. +H\"{a}tten wir SQLite genommen, w\"{a}re die Bestimmung der Datenbankgr\"{o}{\ss}e +viel einfacher gewesen, da SQLite alle Daten in einer einzigen Datei speichert, +dann aber h\"{a}tten wir nicht so einfach erkennen k\"{o}nnen, welche der Tabellen +den meisten Speicherplatz ben\"{o}tigt. -Note, SQLite databases may be as much as 50\% larger than MySQL databases due -to the fact that all data is stored as ASCII strings. That is even binary -integers are stored as ASCII strings, and this seems to increase the space -needed. +SQLite Datenbanken k\"{o}nnen bis zu 50 \% gr\"{o}{\ss}er sein als MySQL-Datenbanken +(bei gleichem Datenbestand), weil bei SQLite alle Daten als ASCII-Zeichenketten gespeichert werden. +Sogar bin\"{a}re Daten werden als ASCII-Zeichenkette dargestellt, und das scheint den Speicherverbrauch +zu erh\"{o}hen. \ No newline at end of file