| | |
| | | user-friendly-plural-name=Lokale DB-Backends |
| | | synopsis=Der lokale DB-Backend verwendet die Berkeley DB Java Edition zum Speichern von Daten die der Benutzer angegeben hat, in einem lokalen Repository. |
| | | description=Es ist der herk\u00f6mmliche "Directory-Server"-Backend, der den vom Sun Java System Directory Server bereitgestellten Backends \u00e4hnlich ist. Der lokale DB-Backend speichert die Eintr\u00e4ge in einem codierten Format und stellt auch Indizes bereit, mit denen auf Basis unterschiedlicher Kriterientypen Zieleintr\u00e4ge schnell gesucht werden k\u00f6nnen. |
| | | property.backend-id.synopsis=Gibt einen Namen an, um den assoziierte Backend zu identifizieren. |
| | | property.backend-id.description=Der Name muss innerhalb aller Backends im Server eindeutig sein. Die Backend-Id kann nach dem Anlegen im Server nicht mehr ver\u00e4ndert werden. |
| | | property.base-dn.synopsis=Gibt die Basis-DN(s) der Daten die ein Backend verwaltet an. |
| | | property.base-dn.description=Ein einzelnes Backend kann f\u00fcr eine oder mehrere Basis-DNs verantwortlich sein. Achtung: Die selbe Basis-DN kann nicht innerhalb von zwei Backends definiert sein, aber ein Backend darf eine Basis-DN verwalten welche unter einer anderen Basis-DN liegt, die durch ein anderes Backend verwaltet wird. (\u00e4hnlich der Benutzung von Sub-Suffixen im Sun Java System Directory Server) Falls irgendeine Basis-Dn eine untergeordnete DN einer Basis-Dn die durch ein anderes Backend verwaltet wird ist, dann m\u00fcssen alle Basis-DNs f\u00fcr das Backend zur selben Basis-DN untergeordnet sein. |
| | | property.base-dn.requires-admin-action.synopsis=Es ist standardm\u00e4ssig keine Admint\u00e4tigkeit vonn\u00f6ten. Es kann aber sein, dass Admint\u00e4tigkeit auf einer pro Backend Basis ben\u00f6tigt wird bevor eine neue Basis-DN benutzt werden kann. |
| | | property.backend-id.synopsis=Gibt einen Namen an, der den verkn\u00fcpften Backend kennzeichnet. |
| | | property.backend-id.description=Der Name muss unter allen Backends im Server eindeutig sein. Die Backend-ID darf nicht ge\u00e4ndert werden, nachdem der Backend im Server erstellt wurde. |
| | | property.base-dn.synopsis=Gibt die Basis-DN(s) f\u00fcr die Daten an, die der Backend verarbeitet. |
| | | property.base-dn.description=Ein einzelner Backend kann f\u00fcr einen oder mehrere Basis-DNs verantwortlich sein. Beachten Sie, dass zwei Backends niemals den gleichen Basis-DN haben d\u00fcrfen, obwohl ein Backend \u00fcber einen Basis-DN verf\u00fcgen kann, der unter dem Basis-DN eines anderen Backends liegt (\u00e4hnlich wie bei der Verwendung von Subsuffixen im Sun Java System Directory Server). Wenn einer der Basis-DNs einem Basis-DN f\u00fcr einen anderen Backend unterliegt, m\u00fcssen alle Basis-DNs f\u00fcr diesen Backend dem gleichen Basis-DN unterliegen. |
| | | property.base-dn.requires-admin-action.synopsis=Standardm\u00e4\u00dfig ist keine administrative Aktion erforderlich, obwohl unter Umst\u00e4nden eine Aktion f\u00fcr einen Backend erforderlich wird, bevor der neue Basis-DN verwendet werden kann. |
| | | property.compact-encoding.synopsis=Gibt an, ob der Backend beim Codieren von Cache-Eintr\u00e4gen eine kompakte Form verwenden sollen, in der die Attribute und Objektklassens\u00e4tze komprimiert werden. |
| | | property.compact-encoding.description=Beachten Sie, dass diese Eigenschaft nur f\u00fcr die Eintr\u00e4ge selbst gilt und sich nicht auf die Indexdaten auswirkt. |
| | | property.compact-encoding.requires-admin-action.synopsis=\u00c4nderungen an dieser Einstellung gelten nur f\u00fcr Schreibvorg\u00e4nge, die nach der \u00c4nderung ausgef\u00fchrt werden. Sie werden nicht r\u00fcckwirkend auf vorhandene Daten angewandt. |
| | |
| | | property.db-txn-no-sync.description=Wenn der Wert des Konfigurationsattributs auf "true" festgelegt wird, kann die Schreibleistung verbessert werden, aber k\u00f6nnen die letzten \u00c4nderungen verloren gehen, wenn der OpenDS-Directory-Server oder die zugrunde liegende JVM abnormal beendet werden oder wenn ein Betriebssystem- oder Hardwarefehler auftritt (ein Verhalten wie das Ausf\u00fchren mit deaktivierter Transaktionsdauerhaftigkeit auf dem Sun Java System-Directory-Server). |
| | | property.db-txn-write-no-sync.synopsis=Gibt an, ob die Datenbank Daten synchron leeren soll, wenn sie auf die Festplatte geschrieben werden. |
| | | property.db-txn-write-no-sync.description=Wenn dieser Wert auf "false" eingestellt ist, werden alle auf die Festplatte geschriebenen Daten synchron in den dauerhaften Speicher geleert. Damit wird vollst\u00e4ndige Dauerhaftigkeit erzielt. Wenn der Wert auf "true" eingestellt wird, k\u00f6nnen die Daten vom zugrunde liegenden Betriebssystem einige Zeit zwischengespeichert werden, bevor sie auf die Festplatte geschrieben werden. Damit kann die Leistung gespeichert werden, aber unter Umst\u00e4nden gehen die letzten \u00c4nderungen verloren, wenn ein Fehler im zugrunde liegenden Betriebssystem oder der Hardware auftritt (aber nicht in F\u00e4llen, in denen der OpenDS-Directory-Server oder die JVM abnormal beendet werden). |
| | | property.enabled.synopsis=Gibt an, ob das Backend im Server aktiviert ist. |
| | | property.enabled.description=Wenn ein Backend nicht aktiviert ist, sind die entsprechenden Daten f\u00fcr die Verarbeitung nicht verf\u00fcgbar. |
| | | property.enabled.synopsis=Gibt an, ob der Backend im Server aktiviert ist. |
| | | property.enabled.description=Wenn der Backend nicht aktiviert ist, ist sein Inhalt beim Verarbeiten von Vorg\u00e4ngen nicht zug\u00e4nglich. |
| | | property.entries-compressed.synopsis=Gibt an, ob der Backend versuchen soll, Eintr\u00e4ge vor dem Speichern in der Datenbank zu komprimieren. |
| | | property.entries-compressed.description=Beachten Sie, dass diese Eigenschaft nur f\u00fcr die Eintr\u00e4ge selbst gilt und sich nicht auf die Indexdaten auswirkt. Au\u00dferdem beruht die Wirksamkeit der Komprimierung auf dem Typ der Daten im Eintrag. |
| | | property.entries-compressed.requires-admin-action.synopsis=\u00c4nderungen an dieser Einstellung gelten nur f\u00fcr Schreibvorg\u00e4nge, die nach der \u00c4nderung ausgef\u00fchrt werden. Sie werden nicht r\u00fcckwirkend auf vorhandene Daten angewandt. |
| | |
| | | property.index-entry-limit.synopsis=Gibt die maximale Anzahl der Eintr\u00e4ge an, die mit einem angegebenen Indexschl\u00fcssel abgestimmt werden k\u00f6nnen, bevor dieser Indexschl\u00fcssel nicht mehr beibehalten wird. |
| | | property.index-entry-limit.description=Diese Eigenschaft ist analog zu ALL IDs -Schwellenwerten im Sun Java System Directory Server. Beachten Sie, dass dies das Standardlimit f\u00fcr den Backend ist, und er kann f\u00fcr jedes einzelne Attribut \u00fcberschrieben werden. Ein Wert von 0 bedeutet, dass kein Limit besteht. |
| | | property.index-entry-limit.requires-admin-action.synopsis=Wenn Indexschl\u00fcssel dieses Limit bereits erreicht haben, m\u00fcssen die Indizes neu erstellt werden, bevor sie das neue Limit verwenden k\u00f6nnen. |
| | | property.java-class.synopsis=Gibt den vollqualifizierten Java-Klassennamen an, welche die Backend-Implementierung bereitstellt. |
| | | property.java-class.synopsis=Gibt den vollst\u00e4ndig qualifizierten Namen der Java-Klasse an, die die Backend-Implementierung bereitstellt. |
| | | property.je-property.synopsis=Gibt die Datenbank- und Umgebungseigenschaften f\u00fcr die Berkeley DB Java Edition-Datenbank an, die die Daten f\u00fcr diesen Backend bedient. |
| | | property.je-property.description=Mit dem folgenden Format kann jede Berkeley DB Java Edition-Eigenschaft angegeben werden: property-name=property-value. Die OpenDS-Dokumentation enth\u00e4lt weitere Infomationen zu verwandten Eigenschaften, ihrer Bedeutung und den Bereichswerten. Die definitive Identifizierung aller Eigenschaftsparameter, die in der Datei example.properties in der Berkeley DB Java Edition-Distribution verf\u00fcgbar sind. |
| | | property.preload-time-limit.synopsis=Gibt die Zeitspanne an, in der der Backend "Vorlade"-Daten verbrauchen kann, wenn er initialisiert wird. |
| | | property.preload-time-limit.description=Der Vorladeprozess wird zum Vorf\u00fcllen des Datenbankcaches verwendet, damit er schneller verf\u00fcgbar ist, wenn der Server Abfragen verarbeitet. Eine Zeitspanne von null bedeutet, dass kein Vorladen stattfindet. |
| | | property.writability-mode.synopsis=Gibt das Verhalten an, welches das Backend annehmen soll, wenn Schreiboperationen durchgef\u00fchrt werden. |
| | | property.writability-mode.syntax.enumeration.value.disabled.synopsis=Bewirkt, dass alle Schreiboperationen fehlschlagen. |
| | | property.writability-mode.syntax.enumeration.value.enabled.synopsis=Erlaubt, dass Schreiboperationen im Backend durchgef\u00fchrt werden k\u00f6nnen. Trifft dann zu, wenn die angeforderte Operation g\u00fcltig ist, der User berechtigt ist, die Operation auszuf\u00fchren, das Backend den Typ von Schreiboperation unterst\u00fctzt und die globale Beschreibbarkeitsmodus-Eigenschaft aktiviert ist. |
| | | property.writability-mode.syntax.enumeration.value.internal-only.synopsis=Bewirkt, dass externe Schreiboperatioenen fehlschlagen, erlaubt jedoch das Schreiben durch Replikation oder interne Operationen. |
| | | relation.local-db-index.user-friendly-name=Lokaler DB-Index |
| | | relation.local-db-index.user-friendly-plural-name=Lokale DB-Indizes |
| | | relation.local-db-index.synopsis=Lokale DB-Indizes werden zum Speichern von Informationen verwendet, die es erm\u00f6glichen, Eintr\u00e4ge sehr schnell ausfindig zu machen, wenn Suchvorg\u00e4nge verarbeitet werden. |
| | | relation.local-db-index.description=Die Indizierung wird auf Ebene jedes einzelnen Attributs ausgef\u00fchrt, und an unterschiedlichen Attributstypen k\u00f6nnen unterschiedliche Indizierungstypen ausgef\u00fchrt werden, abh\u00e4ngig davon, wie w\u00e4hrend Suchvorg\u00e4ngen auf sie zugegriffen werden soll. |
| | | property.writability-mode.synopsis=Gibt das Verhalten an, das der Backend verwenden soll, wenn er Schreibvorg\u00e4nge verarbeitet. |
| | | property.writability-mode.syntax.enumeration.value.disabled.synopsis=Verursacht ein Fehlschlagen aller Schreibversuche. |
| | | property.writability-mode.syntax.enumeration.value.enabled.synopsis=Erlaubt Schreibvorg\u00e4nge in diesem Backend (wenn der angeforderte Vorgang g\u00fcltig ist, der Benutzer die Genehmigung zum Ausf\u00fchren des Vorgangs hat, der Backend diesen Typ des Schreibvorgangs unterst\u00fctzt und die Eigenschaft globaler Beschreibbarkeitsmodus ebenfalls aktiviert ist). |
| | | property.writability-mode.syntax.enumeration.value.internal-only.synopsis=Verursacht ein Fehlschlagen externer Schreibvorg\u00e4nge, aber erlaubt Schreibvorg\u00e4nge durch Replikation und interne Vorg\u00e4nge. |
| | | relation.local-db-index.user-friendly-name=Lokaler Datenbankindex |
| | | relation.local-db-index.user-friendly-plural-name=Lokale Datenbankindizes |
| | | relation.local-db-index.synopsis=Lokale Datenbankindizes werden zum Speichern von Informationen verwendet, die es erm\u00f6glichen, Eintr\u00e4ge sehr schnell ausfindig zu machen, wenn ein Suchvorgang verarbeitet wird. |
| | | relation.local-db-index.description=Die Indizierung wird auf Pro-Attribut-Ebene ausgef\u00fchrt. Unterschiedliche Indizierungstypen m\u00fcssen f\u00fcr unterschiedliche Arten von Attributen ausgef\u00fchrt werden. Dies h\u00e4ngt davon, wie auf sie w\u00e4hrend der Suchvorg\u00e4nge zugegriffen wird. |
| | | relation.local-db-vlv-index.user-friendly-name=Lokaler Datenbank-VLV-Index |
| | | relation.local-db-vlv-index.user-friendly-plural-name=Lokale Datenbank-VLV-Indizes |
| | | relation.local-db-vlv-index.synopsis=Lokale Datenbank-VLV-Indizes werden verwendet, um Informationen zu einer bestimmten Suchabfrage zu speichern. Damit wird es erm\u00f6glicht, \u00fcber die VLV-Steuerung effizient zu suchen. |
| | | relation.local-db-vlv-index.description=Ein VLV-Index benachrichtigt den Server, dass eine virtuelle Listenansicht mit spezifischen Abfrage- und Sortierparameter ausgef\u00fchrt wird. Dieser Index erm\u00f6glicht es dem Server auch, die Informationen zu erfassen und zu speichern, die zum Beschleunigen der virtuellen Listenansicht ben\u00f6tigt werden. |
| | | relation.local-db-vlv-index.description=Ein VLV-Index benachrichtigt den Server effizient, dass eine virtuelle Listenansicht mit bestimmten Abfrage- und Sortierparametern ausgef\u00fchrt wird. Dieser Index erm\u00f6glicht es dem Server auch, die Informationen zu erfassen und beizubehalten, die zur Beschleunigung der virtuellen Listenansicht erforderlich sind. |