[gelöst] NAV + SQL Server auf 6 HDDs verteilen

Hallo zusammen,

ich möchte auf einen Server mit 6 HDDs NAV 5.01 und SQL Server 2005 installieren.
Habe schon einiges über die Vorkehrungen zur Sicherheit der Daten gelesen.
Habe aber immer noch keine klare Vorstellung davon, wie ich die HDDs aufteilen soll.

Server: FS Primergy, 2x 3,16 Quadcore, 16GM Ram, HDD: 2x 73GB und 4x 146GB

Habe 4x 146GB im Raid10 zusammengefasst , 2x73 in Raid1.

Will nun die NavisionDaten auf das Raid10 legen, das TransactionLog auf das Raid 1.
Allerdings hat das Raid1 "nur" 73GB, wobei dort auch das Betriebssystem liegen soll (und auch die anderen SQL Tabellen wie master usw).

Wie groß kann denn eigentlich das TransactionLog werden? Wenn es voll ist, wird es dann überschrieben?
Sind etwa 60 concurrend User.
Würde es reichen, Laufwerk C:\ 20GB und Laufwerk D:\ 50GB auf dem Raid1 zu partitionieren (C:\ für Betriebssystem+masterDB, D:\ für TransactionLog)??????
Laufwerk E:\ wäre mit 312GB für die NAVDatenbank vorgesehen?

Oder kann ich auf dem Raid10 z.B. Laufwerk D.\ und E:\ anlegen und dort das TransactionLog (D:\) und die NAVDaten (E:\) ablegen? Soll, gleube ich, nicht so sein, da das TransactionLog und die NAVDaten ja auf physikalisch getrennten Fetsplatten leigen sollen, oder??

Weiß jemand Rat?

Danke schonmal im Voraus...
naviii

Zuletzt geändert von Naviii am 18. Dezember 2008 10:33, insgesamt 1-mal geändert.

Hallo Naviii,

wie groß ist deine jetzige Datenbank, bzw. mit was für einem Datenvolumen rechnest du?

Mir scheint da fehlt mindestens noch in Raid1 fürs Log, denn mit 20GB fürs OS bist du sehr an der unteren Grenze. Ich würde die 73 GB fürs OS lassen und evtl. noch TemDB drauf tun.
Das LOG kann im Zweifelsfall sehr groß werden. Spielst du z.B. eine FBK-Datensicherung aus NAV ein, wird das LOG sehr groß, denn der Restore ist eine Transaktion.

Gruß, Fiddi

Korrigiert mich, wenn ich mich irre, aber die Log-Dateien wachsen doch eigentlich schneller als die eigentlichen Daten. Warum nicht 3x Raid (2x 2x146, 2x73) und dann System, Daten, Log. Bleibt ggf noch die Auslagerunsdatei vom Systemlaufwerk wegzuschieben.

Volker

@vsnase

Es ist schon korrekt, dass die Logdateien schneller wachsen als die Datenbank. Wie groß sie allerdings wird, hängt von deinem Wiederherstellngsmodell und deinem Datensicherungsmodell ab.

Gruß, Fiddi

Hallo naviii,
ich würde Dir folgenden Weg vorschlagen. Da Du ja warscheinlich in Deinen Server nicht mehr Platten hineinbekommst ist die Konfiguration nicht so schön, wie sie optimal sein sollte.
Installiere den SQl Server auf C. Lasse die Systemdatenbanken auf D anlegen. Installieren dann das aktuelleste SP für den SQl Server und installiere alle Hotfixe aus dem microsoft Update Service.
dann gehe auf Dein Raid 10. Lege 2 Partitionen an. 1. Partition 52 GB NTFS Standardblockgröße. Dort legst Du am besten einen ordner Data1 an. 2. Partition den Rest (musste so an die 230 GB sein) NTFS Blockgröße 64K (größte Blockgröße). Dort legst Du dann den Ordner Data2 an. Gehst dann auf D und legst dort LOG an.

Wenn dass alles erledigt ist, gehts Du in den SQl Server. Im Management Studio gehst Du dann auf der linken Seite auf Deinen SQl Server. Rechte Maustaste Eigeschaften. Unter datenbankeinstellungen, gehst du zu Daten und suchst dort den ordner DATA1, den Du vorher angelegt hast. Bei log das gleiche nur auf D mit dem Verzeichnis LOG.

Dann legst Du eine neue Datenbank direkt im SQl Server an. Dort legst nur eine Datei für die Primäre Dateigruppe im Ordner DATA1 an und die Logdatei in Deinen Ordner LOG.

Dann lege auf dem SQl Server einen SQLServer Account an, der Sysadmin ist.

Nach dem das erledigt ist, Öffnest Du Navision. Öffnest die neue angelegte Datenbank mit dem angelegten SQL nutzer. erstellst einen neuen Mandanten mit einem Mandantennamen, der in Deiner bisherigen Datenbank nicht existiert.

Dann gesht Du in Navision unter Datei Datenbanken Ändern. Geshts auf die Registerkarte optionen Wählst als Wiederherstellungsform Voll aus und hakst automatisch verkleinern an. Danach gesht Du auf Erweitert, nimmst den Haken bei Sperre Timeout raus und setzt ihn bei Immer Zeilensperre. Wählst bei Sicherheit Modell Standard aus und sagts ok. dann Schließe Navision mit Deiner neuen Datenbank

Dann solltest Du Dir aus Deiner Alten Datenbank alle Objekte exportieren und in die Neue Datenbank importieren. Wenn alle Schlüssel angelegt wurden, erstellst Du Dir eine Datensicherung Deiner alten Datenbank ohne Applikationsobjekte aller Deiner Mandanten.

Dann gehst Du wieder auf den SQL Server, rechte Maustaste auf deine Datenbank und wählst Eigenschaften. Unter Dateigruppen legst Du eine neue Dateigruppe Daten an und setzt den Haken bei Standard. Danach gesht Du auf Dateien und erstellst eine neue Datenbankdatei vom Typen Daten in der Dateigruppe Daten an und speichere diese in Deinem Ordner DATA2.

Danach öffnest Du wieder Navision mit dem SQl Benutzer und sicherst Deine Datensicherung ohne die Applikationsobjekte wieder zurück in die neue Datenbank.
Nach dem die Rücksicherung abgeschlossen ist, gehst Du in Navision auf Extras/ Sicherheit und dann Datenbankbenutzer. Hier alle entfernen und Deinen jetzigen SQl Nutzer eintragen. Dem SQl Nutzer dann Superrechte geben. das machst Du bitte nicht mit den Windowsnutzern.

danach Gehst Du auf Extras/ Sicherheit Alle synchronisieren und Navision legt Dir alle Windowsbenutzer in der Datenbank an.

dann biste fertig.

Damit sich ein Transaktionslog wieder verkleinert, Solltest Du täglich eine Vollsicherungen machen und mehrmals tägliche eine Transaktionsprotokollsicherung. dann bleiben die Logs klein. Machst Du es nicht, kann es sein, dass der Server Dir voll läuft.

Achso Bei 60 Usern hätte ich dem Server 32 GB RAM gegeben. Insgesamt 5 RAIDS angelegt.
1. RAID RAID1 System
2. RAID RAID10 mit 4x146 GB für Daten1
3. RAID RAID10 mit 8x146 GB für Daten2
4. RAID RAID1 mit 2x146 GB für LOG
5. RAID RAID5 mit 6x146 GB für Deine Datensicherung

Das Serverbetriebssystem sollte ein Windows 2003R2 SP2 64bit sein. der SQl Server 2005 Standard 64bit. das wäre bei der Hardware die optimalste Konfiguration. Bei fragen stehe ich Dir gerne per PN zur Verfügung.

MFG

Sven

dann gehe auf Dein Raid 10. Lege 2 Partitionen an. 1. Partition 52 GB NTFS Standardblockgröße. Dort legst Du am besten einen ordner Data1 an. 2. Partition den Rest (musste so an die 230 GB sein) NTFS Blockgröße 64K (größte Blockgröße). Dort legst Du dann den Ordner Data2 an. Gehst dann auf D und legst dort LOG an.

Nur um ein paar Dinge herauszustellen: "Logische Partitionen" haben in einem Datenbanksystem - vor allem mit SQL Server - nix zu suchen; wir reden hier ausschliesslich von "Physikalischen Laufwerken"!
Insbesondere für das Transaction Log ist es absolut notwendig, dies auf einem dedizierten physikalischen Laufwerk alleine unterzubringen! Dort wo das TLog gespeichert ist, befindet sich nix anderes - ZIel der Aktion ist es, den Schreib-Lese-Kopf der Spindel(n) permanent an der Position zu belassen, wo als nächsten physikalisch zugegriffen wird.

Das mit der Formattierung auf 64kB bewirkt nicht wirklich was, schadet aber auch nix.

Achso Bei 60 Usern hätte ich dem Server 32 GB RAM gegeben. Insgesamt 5 RAIDS angelegt.
1. RAID RAID1 System
2. RAID RAID10 mit 4x146 GB für Daten1
3. RAID RAID10 mit 8x146 GB für Daten2
4. RAID RAID1 mit 2x146 GB für LOG
5. RAID RAID5 mit 6x146 GB für Deine Datensicherung

Das ist m.E. schon ein wenig sehr großzügig bemessen. Je mehr RAM desto besser, aber 16 bis 24GB solten schon reichen, ausser es wird rel. hohe Transaktionslast erwartet. 64bit Architektur sollte schon sein. Das Disk-Subsystem könnte auch so aussehen:

1. RAID1 (2 x HDD) OS, Swap, Programme, SQL Server (master, model, msdb)
2. RAID1/0 (2 x HDD) tempdb
3. RAID1/10 (2/4 x HDD) NAV DB (mdf/ndf)
4. RAID1/10 (2/4 x HDD) NAV DB (ldf)
5. RAID1 (2 x HDD) Backups & Verschiedens

RAID5 hat in Datenbanksystemen ebenfalls nix zu suchen; nicht einmal für Backups, da die Schreibleistung grotten schlecht ist. Wenn es um das "striping" im RAID geht, dann sollten nach Möglichkeit mehrere kleine Disks als wenige große Disks verwendet werden; abhängig von der Kapazität der RAID-Controller. Auch die Disk-Technologie spielt eine Rolle: SAS ist mit einem Durchsatz von 3,2Gbit/sec zehn-mal besser als uSCSI320 (320 Mbit/sec); SATA sollte heutzutage nicht megr verwendet werden. Oder auch ein kleiens SAN via FiberChannel oder iSCSI könnte vorteilhaft sein. Auch die Platten selbst sollten min. 10k rpm (besser 15k) leisten ...

Gruß,
Jörg

@stryk

SAS -Platten mit 3,2GBit/s sind leider langsamer (ca. 300 MByte/s Netto lt. Wikipedia) als eine u320-SCSI-Platte mit 320 MByte/s. Dadurch das die SAS- Platten aber einen eigenen Anschluss an den Controller haben, und sich keinen BUS wie beim normalen SCSI mit anderen Platten teilen müssen, wird dann schon wieder ein Schuh draus. Außerdem sind SAS-Platten physikalisch (Kabel, Anschlüsse,..) identisch zu SATA. Deshalb gibt es auch Controller die beides können . Der Vorteil der SAS-Platten liegt in der höheren Drehzahl (10 kU/Min bei 2,5"-Platten, 15kU/Min bei 3,5"), bessere Zugriffszeiten und der Auslegung auf Server-Betrieb (24/7- Dauerbetrieb).

Zur Plattenkonfiguration noch eine Info: (Zitat aus dem Microsoft Trainingsbuch zur Prüfung 70-431 'Implementieren und Warten SQL- Server 2005' aus 2006)

RAID5: Die häufigste RAID-Ebene, verteilt die Daten wie RAID0 auf die einzelnen Stripes, fügt jedoch zur Fehlertolleranz Paritätsinformationen hinzu, die über alle Datenträger verteilt werden. Die Geschwindigkeit ist höher als bei RAID1; fällt jedoch ein Datenträger aus , sinkt die Leseleistung

Welche RAID-Konfiguration für Ihre Datenbankdateien am günstigsten ist, hängt von mehreren Faktoren ab, beispielsweise den Anforderungen an Leistung und Wiederherstellbarkeit. RAID10 empfiehlt sich für Transaktionsprotokoll-, Daten- und Indexdateien. Bei beschränktem Budget sollten Sie das Transaktionsprotokoll in einen RAID10- System unterbringen, die Daten- und Indexdateien dagegen in einem RAID-5 System.

Was man von solchen Aussagen halten kann, müsste man mal testen, denn so alt ist das Buch auch noch nicht. Der folgende Link ins MSDN empfiehlt auch für SQL-Server 2008 RAID10 bzw. RAID5 aber nicht RAID1 wg. der niedrigeren Schreibleistung.

Gruß, Fiddi

Gut, was die Durchsatztraten angeht so muss man zugegeben etwas präziser sein:

USB1 1.2 Mbit/s = ca 150KB/s
USB1.1 12 Mbit/s = ca 1.5 MB/s
USB2 480 Mbit/s = ca. 60 MB/s
Firewire 1394a 400Mbit/s = ca 50 MB/s
Firewire2 1394b 800 Mbit/s = ca. 100 MB/s
SATA = 1200 Mbit/s = ca 150MB/s
SATA2 = 2400Mbit/s = ca 300MB/s (3000Mbit/s)
PATA = 1064Mbit/s = ca 133MB/s (UDMA6)
Netzwerk 100Mbit/s = ca 12.5MB/s
Netzwerk wired 1000 Mbit/s = ca 125MB/s
SCSI-1 = 40 Mbit/s = ca. 5 MB/s
SCSI-2 = 160 Mbit/s = ca 20 MB/s
SCSi-3 oder auch Ultra SCSi = 320 Mbit/s = ca 40 MB/s
Ultra 2 SCSI = 640 Mbit/s = ca 80 MB/s
Ultra 3 SCSI = 1280 Mbit/s = ca 160 MB/s
Ultra 320 = 2560 Mbit/s = ca 320 MB/s
Ultra 640 = 5120 Mbit/s = ca 640 MB/s
SAS bis zu 12Gbit/s = ca 1.5GB/s

(die Liste habe ich mir mal aus 'nem echten Hardware/Technik-Forum kopiert)

Natürlich macht es keinen Sinn "Äpfel mit Birnen" zu vergleichen, aber unter Strich gilt: SAS vor uSCSI vor SATA. ('Tschuldigung, aber Wiki ist nicht unbedingt als DIE technische Referenz zu betrachten; die Hersteller liefern wohl zu zuverlässigeren Zahlen) - SAS bietet die höchsten Durchsatzraten (von der besseren MTBF u.a. ganz zu schweigen).

Zu RAID5: RAID5 ist ein billerger Kompromiss zu RAID10; bei RAID5 braucht man min. 3 Disks, bei RAID10 benötigt man min. 4; deshalb ist RAID5 soz. "um eine Disk" billiger als RAID10. Allerdings bremst das berechnen/schreiben der Partitätszahlen die Schreibtransaktionen deutlich ab, und ist deshalb ein ABSOLUTES NO-GO für Datenbanken. Aus. Schluss. Ende der Diskussion. Es Jahre gedauert um dieses RAID5 endlich aus den NAV Dokus 'rauszubekommen (ich hoffe das ist auch noch so!). Nur weil RAID5 billiger ist als 10 heisst das ja noch lange nicht, das es auch gut ist.

Der Grundansatz sollte IMHO folgender sein:

RAID1 (mirroring) ist für produktive Server Pflicht aufgrund der Fehlertoleranz
RAID0 (striping) immer da wo eine physikalische Lastverteilung erforderlich ist; also schnelles Schreiben das Ziel ist
RAID10 (mirroring/striping) (oder auch 01) also immer dann wenn's sicher und schnell sein muss

Es sei noch zu erwähnen, dass bestimmte SAN Systeme sehrwohl RAID Level 4,5 oder 6 u.ä. fahren, das hat aber nix mit den obigen Anforderungen zu tun ...

@stryk

zu der SAS-Geschwindigkeit muss man allerdings sagen, das SAS zwar bis 12Gbit/s definiert ist, aber z.Zt. gerade die ersten Produkte mit 6Gbit/s verfügbar sind. Aktuell sind daher Produkte mit 3Gbit/s, was ca. 300Mbyte/s entspricht.
Laut Roadmap der STA (Standardseite für Serial Attached SCSI) ist SAS mit 12GBit/s erst für 2012 geplant und 6Gbit für Ende dieses Jahres. Daher zieht SAS die Geschwindigkeit z.Zt. aus der direkten 1zu1-Verbindung von Platte und Controller, und nicht wie bei u320, wo sich alle Platten an einem Controllerkanal die Bandbreite teilen müssen.

SCSI3 hat laut t10 nicht direkt mit der Geschwindigkeit des SCSI-Bus zu tun, denn SCSI3 definiert z.B. auch SAS.

Gruß, Fiddi

Hi,

ich denke Du solltest den Platz bei Deinem Server etwas großzügiger gestalten, wenn Du nur 73 GB hast und dann noch das Betriebssystem, SQL Server usw. drauf habst, dann brauchst du bei 16 Gigabyte arbeitsspeicher mind. das doppelte (32 GB) für die pagefile sys!

ICh denke wenn Du ein Storage System hast das sich ja in erster Linie über Raid Level und möglichst hohe anzahl an spindeln definiert sollt der datendurchsatz kein problem sein.

Gruß
Tesa.

Wieso brauch ich bei 16GB RAM mindestens eine Pagefile mit 32GB? MS empfiehlt das ca. 1,5 fache und bei großen RAM-Mengen ggf. weniger. Es hängt aber letztendlich doch alles davon ab, wieviele Prozesse auf dem Server laufen. Und 32-bit Prozesse können auch auf einem 64-bit Server nicht plötzlich mehr als 2 GB verwenden/belegen. Abgesehen davon muß die Pagefile nicht auf c oder dem Systemlaufwerk liegen. Problematisch ist eher, dass 6 Platten nicht die optimale SQL-Server-Maschine darstellen, nur das läßt sich ja wohl in diesem Fall nicht so einfach ändern.

Hi,

also ich habe die erfahrung gemacht das die pagefile sys meist genau das doppelte an platz einnimmt um sicher zu gehen würde ich mit dem doppelten rechnen. wir haben z.b. einen 32 gb sql server und die pagefile sys ist nun seit monaten genau auch auf dieser größe. ach so du hast nur 32 bit ok dann spielt das nicht so die rolle, da kannst du ja nur 4gb verwenden max.

Hallo zusammen,

vielen, vielen Dank für die sehr ausführlichen Beschreibungen.
Das Hauptproblem sind bei mir nun leider die begrenzte Anzahl von nur 6 HDDs, wobei 2 nur 73GB haben.

Da die zu importierende NAV DB zurzeit ca. 50GB hat und sie seit ca. 5 Jahren auf NAV 3.6 läuft, rechne ich damit, dass ich mit einem RAID10 für die NAV DB mit einer Größe von ca. 140GB auskomme.
Deshalb folgender Entschluss:

Zur Erinnerung:
Es stehen folgende HDDs zur Verfügung: 4x 146GB SAS(15k), 2x 73GB SAS (15k)
Raid10 aus 2x 73GB und 2x 146GB -> Ich weiß, dass dadurch Plattenplatz verschwendet wird (ist nicht nutzbar), da die Summe des Raid10 dann bei ca. 140GB liegt. Aber das sollte für die NAV DSB reichen.

Raid1 aus 2x 146GB für C:\ (OS, SQL) und D:\Transaction Log.
Ich denke, wenn der Server hochgefahren ist und alles läuft, sind die Plattenzugriffe druch das OS auf C:\ nicht mehr so häufig, sodass es doch reichen sollte, das TLog auf D:\ zu legen.

@stryk: Das TLog liegt dann jedoch nicht auf einem dedizierten physikalischen Laufwerk alleine. Obwohl es Deiner Erfahrung nach wohl notwendig ist. Ich hoffe, es geht auch so, wie geplant.

Für die SQL Sicherungen habe ich gedacht:
Vollsicherung: 1x die Woche
Incremantal: jeden Tag
TLog: alle 3 Stunden.

Die Sicherung wird aber aufgrund des geringen Plattenplatzes über`s Netzwerk auf einen anderen Rechner geschehen.

Ist meine Idee mit der Umsetzung so i.O.? Ich hoffe, es geht alles so, wie ich es mir vorstelle.

@Dreistein:
Vielen vielen Dank für Deine sehr umfangreiche Antwort.

Gruß,
Tomas

Da die zu importierende NAV DB zurzeit ca. 50GB hat und sie seit ca. 5 Jahren auf NAV 3.6 läuft, rechne ich damit, dass ich mit einem RAID10 für die NAV DB mit einer Größe von ca. 140GB auskomme.
Deshalb folgender Entschluss:
Zur Erinnerung:
Es stehen folgende HDDs zur Verfügung: 4x 146GB SAS(15k), 2x 73GB SAS (15k)
Raid10 aus 2x 73GB und 2x 146GB -> Ich weiß, dass dadurch Plattenplatz verschwendet wird (ist nicht nutzbar), da die Summe des Raid10 dann bei ca. 140GB liegt. Aber das sollte für die NAV DSB reichen.

Wie wär's mit folgender Alternative:

C:\ RAID1 (2 x SAS 73GB) OS, Swap, Programme, SQL Server (master, model, msdb, tempdb)
D:\ RAID1 (2 x SAS 146GB) NAV Datenbank (mdf/ndf)
E:\ RAID1 (2 x SAS 146GB) NAV Datenbank (ldf)

D.h. ich würde "dedizierten I/O" dem "Striping" vorziehen. Wie gesagt, hinsichtlich guter Performance ist es absolut entscheidend, dass das LW des "Transaction Logs" so schnell wie möglich funktioniert - alle Transaktionen hängen letztlich davon ab! - und das erreicht man nur mit exclusivem Zugriff (wie gesagt: nur mit SAN läuft's ein wenig anders).

Für die SQL Sicherungen habe ich gedacht:
Vollsicherung: 1x die Woche
Incremantal: jeden Tag
TLog: alle 3 Stunden.

Hmmm ... also ich persönlich halte 1 x Full-Backup pro Woche für zu riskant - im "Worst Case" verliert ihr eine ganze Woche an Daten. IMHO ist es ein absolutes Muss, einmal am Tag ein Full-Backup zu haben (bezogen auf die NAV DB; master, msdb und ggf. model reichen einmal pro Woche) ...
Bei begrenztem Speicherplatz würde ich dann auf die "Differentials" (gibt keine "Incrementals"!) verzichten und z.B. jede Stunde das TLog sichern.

Letzten Endes hängt ja die Backup-Strategie vom "Maximal zu akzeptierenden Datenverlusst" ab; und dann natürlich vom verfügbaren Speicherplatz. Wenn "Speicherplatz" ein Problem ist, dann könnte man Komprimierungstools erwägen; z.B. Backup-Compression in SQL Server 2008 (Enterprise!) oder 3rd-party Tools wie "Lite Speed" von Quest: http://www.quest.com/sql-server/backup-and-recovery.aspx
Allerdings kostet das Zeug auch einiges ...

Hallo stryk ,

vielen Dank für Deinen Vorschlag.
Das FullBackup werde ich dann häufiger als 1x die Woche durchführen.

Meinst Du denn, dass die Konfiguration, so wie ich sie vorgeschlagen hatte, finktioniert?

Noch eine andere Frage:
Ist es eigentlich sinnvoll, auf dem Server (auf dem ja nur eine NAV Installation laufen wird) eine "VMware ESX Server 3i" zur Virtualisierung zu benutzen?
Stimmt es, dass der Server dann "schneller" läuft? Kann ich mir nämlich nicht vorstellen. Hast Du da Erfahrungen?

Danke,
naviii

Meinst Du denn, dass die Konfiguration, so wie ich sie vorgeschlagen hatte, finktioniert?

Du meinst das HDD-Layout?
Nun, grundsätzlich funktionieren wird das schon, aber eben nicht unbedingt performant. Wenn Du 1 x RAID1 (2 x SAS 146GB) baust und dieses Volume logisch in C:\ und D:\ partitionierst - C:\ OS, SQL und D:\ TLog - dann ist für das TLog nix gewonnen. Die Isolation des TLog macht nur auf echten physikalischen Laufwerken Sinn!

Was ESX/VMWare angeht: Tja, meine bisherigen Erfahrungen mit "virtualisierten SQL Servern" waren durchwegs nicht so prickelnd ... das "Durchreichen" der Hardware-Ressourcen über die V-Schicht dauert m.E. einfach zu lange ... das Ganze könnte schon funktioniern, wenn entsprechend AUSREICHEND Hardware vorhanden ist und dem SQL Server zugeteilt werden kann ... hängt auch davon ab, mit welchen anderen Servern/Systemen/Applikationen die Hardware geteilt werden muss ...
Aber das ein virtueller Server schneller sei als ein echter - korrekt konfigurierter - physikalischer Server halte ich für ein Gerücht (habe ich bisher weder erlebt noch berichtet bekommen)... Virtualisierung dient ja auch nicht dem Gewinnen von Performance, sondern dem Einsparen an Hardware & ggf. Administartionsaufwand, sowie der Ausfallsicherheit.

Hallo stryk,

nochmals vielen Dank für Deine Hilfe.
Werden das ganze nun doch als reines RAID1 System, wie von Dir vorgeschlagen, realisieren, um wenigstens das TLog separat auf einem physikalisch getrenntem LW zu haben..
Danke auch für den HInweis auf die VMware, werden wir nicht benutzen.

Für die "restliche" Installation haben wir uns schon das schöne Buch "The NAV/SQL Performance Field Guide" gekauft. ))

naviii

Nur weil es mir gerade über den Weg läuft: http://support.microsoft.com/kb/889654