DB Sicherung / DB erzeugen / FBK einlesen auf sep. Rechner

4. April 2009 11:35

Hallo Zusammen,

ich habe mal gelesen.., wenn man eine neue DB erstellt, und dann wieder die Sicherung einliest, sollte dies auf einer anderen Rechner bzw. Disk geschehen (NATIV-DB).

Was ist der Grund, und wo gibt es dazu weitere Infos ?

Besten Dank fürs Feedback

Gruß
Stefan

Re: DB Sicherung / DB erzeugen / FBK einlesen auf sep. Rechner

5. April 2009 18:44

Ich kann mir nur einen einzigen plausiblen Grund für solch eine Aussage vorstellen:
Die neue DB wird aufgrund eines Festplattenschadens aus der Datensicherung wiederhergestellt.
Dies sollte logischerweise auf einer anderen Festplatte stattfinden, da die alte Platte ja defekt ist.

In allen anderen Fällen (Test-DB, Schulungs-DB, Entwicklungs-DB, ...) darf die DB auch gerne auf derselben Festplatte liegen.

Falls auf der Festplatte mit der Echt-DB weitere Daten mit häufigen Zugriffen liegen (Schulungs-DBs gehören dazu), kann dies unter Umständen negative Auswirkungen auf die Performance haben, da die Schreib-/Leseköpfe nun nicht mehr exklusiv für die Echt-DB zur Verfügung stehen, sondern auch noch andere Daten lesen und schreiben müssen.

Re: DB Sicherung / DB erzeugen / FBK einlesen auf sep. Rechner

5. April 2009 19:02

Hallo Timo,

ja in deinem geschilderten Fall kann man es nachvollziehen, ansonsten sehe ich auch keinen wirklichen Grund.

Ich habe noch eine andere Frage:
Was ist besser:
Ein grosses File ca. 80GB auf einer Storage-Einheit mit mindestens RAID-10Basis (RAID-Controller verteilt das große File auf die Festplatten 12Stk.)
oder
mehrere kleine Files (sollte irgendwie auch gehen) natürlich auf der gleichen Storage-Einheit, wie oben,
?

Re: DB Sicherung / DB erzeugen / FBK einlesen auf sep. Rechner

5. April 2009 22:05

stefan hat geschrieben:Ich habe noch eine andere Frage:
Was ist besser:
Ein grosses File ca. 80GB auf einer Storage-Einheit mit mindestens RAID-10Basis (RAID-Controller verteilt das große File auf die Festplatten 12Stk.)
oder
mehrere kleine Files (sollte irgendwie auch gehen) natürlich auf der gleichen Storage-Einheit, wie oben?

Das wäre schon wieder ein neues Thema, für welches du hier ebenfalls zahlreiche Diskussionen findest.
Prinzipiell gilt: Eine große Datenbank über mehrere physikalische Platten zu verteilen hat immer irgendwo Performance-Vorteile, da ja mehr Schreib-/Lese-Köpfe für die Anfragen zur Verfügung stehen.
Wieviele Platten bei welcher Größe / welchem Transaktions-Volumen ist ein weiteres Thema.

Mein Tipp: Durchforste diesbezüglich mal die bisherigen Themen. Falls deine Frage dann noch nicht zufriedenstellend beantwortet sein sollte, eröffne dafür ein neues Thema.