[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-adabas
Subject:    =?ISO-8859-1?Q?Re=3A_=5Bsuse-adabas=5D_Migration=3A_Entsch?==?ISO-8859-1?Q?eidung_=FCber_Konfigurati
From:       Detlef Kraska <Detlef.Kraska () mik ! med ! uni-erlangen ! de>
Date:       2003-08-08 10:50:15
[Download RAW message or body]

Hallo,

> wir betreiben seit einiger Zeit unter Linux 2.2 einen Adabas-Server 
> (V11), dessen Devspaces aber leider immer noch vom Typ File sind.
> 
> Durch eine Rechnerumstellung haben wir nun die Gelegenheit,
> die DB auf einen anderen Server (4x36GB-SCSI, 512 MB, PIII-800,
> RAID-Controller, 64 MB Write-Cache) zu migrieren. Dabei möchten wir 
> natürlich die Devspaces als Raw anlegen. 
> 
> Jede dieser Platten ist mehr als ausreichend, um die aktuelle
> Datenmenge (momentan ca. 2 GB bei Füllgrad 60%) zu fassen. Nach Analyse
> der bisherigen Diskussionen dazu auf der Mailingliste tendieren wir
> eher zu einer softwaremäßigen Spiegelung, sind aber nicht sicher, 
> in welchem Mode die DB am besten gefahren werden kann und wie die 
> Devspaces am günstigsten verteilt werden sollten, um einen guten 
> Kompromiss zwischen Performance und Datensicherheit erreichen. 
> 
> Unsere Vorstellung ist bisher so: 
> - erste Platte als Systemplatte
> - DB im Mode Single mit gespiegelten Sys- und Daten-Devspaces auf
>   Platte 2 und 3 sowie Log auf Platte 4
> - den Write-Cache würde ich nach den Empfehlungen von Jörg der 
>   Datensicherheit wegen eher abschalten
> 
> Macht diese Konfiguration Sinn und hat jemand dazu vielleicht Tipps 
> für uns?

Aus Gründen der Verfügbarkeit des Gesamtsystems würde ich eher zwei 
Spiegelsätze anlegen, also jeweils zwei Platten durch den 
RAID-Controller zum RAID 1 zusammenschließen, das gibt zwar insgesamt 
weniger Plattenplatz, was aber in dem Fall hier wohl nicht das Problem ist.

Auf das Plattenpaar 1 würde ich das System, die Daten und das 
SYSDEVSPACE legen, auf das Plattenpaar 2 das Log (Mode Single) und die 
DB-Software.

Den Write-Cache würde ich nicht ausschalten, wir haben das hier mal 
spaßeshalber gemacht und schon beim Hochfahren der Datenbank ewig 
gewartet. Ist der Cache Batterie-gepuffert?

Und was noch am wichtigsten ist: Daten- und Convertercache bis zum 
Anschlag hochsetzen. Die Performance wird gar nicht so sehr von den 
Platten, sondern eher von den Cache-Größen bestimmt. Das gilt natürlich 
für hauptsächlich lesende Anwendungen.

Viele Grüße,
Detlef Kraska


-- 
Um die Liste abzubestellen, schicken Sie eine Mail an:
    suse-adabas-unsubscribe@suse.com
Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken
Sie eine Mail an: suse-adabas-help@suse.com

[prev in list] [next in list] [prev in thread] [next in thread]