Hallo,

heute gibt’s ne große Show von Oracle zur Übernahme von SUN.

Wer Spaß dran hat kann auch die Zwitscherreien online verfolgen. Hier die Twitterwal!

Viele Grüße

Michael

Hi,

und weiter geht der Spaß:

Allerdings glaube ich, das Oracle hier noch was ändern muß: “We didn’t have to buy more hardware”. Passt das noch nach dem Kauf von SUN? Ok, einmal kann man komprimieren – danach heißt es wieder: “Kauf mehr Blech”

Viel Spaß

Michael

PS: ja ja – ich hör jetzt auf ….

Hallo!

Haha die Videos von Oracle auf YouTube fangen an mir zu gefallen.  Hier noch eins:

Da fällt mir sofort der Kunde ein, der meint seine DBA’s können das alles auch per SSH / SQLPlus. Und was soll ich sagen: ja wir können es natürlich auch. Dauert nur ein bisschen länger ….

Scheiß auf Produktivität: Nieder mit den Maus – Schubsern!

Mehr davon gibt es hier!

Viel Spaß

Michael

Hallo,

da flimmert mir doch dieses schöne Video von ORACLE über meinen Bildschirm:

Sie benötigen also zukünftig keinerlei Downtimes mehr für Ihr Datenbanksystem. Oder?

Ich hoffe Oracle selber gestaltet seine Patches für ASM so, das es niemals die Situation gibt, das beide (es könnten auch mehr als zwei sein) Seiten offline sein müssen.

Einige Installationen die ich kenne beruhen auf einer Architektur die auf Clusterfilesysteme zurückgreift (statt ASM). Bei Patches für diese Produkte kommt es sehr wohl zu Downtimes für beide Seiten gleichzeitig. Vielleicht nicht für einen gewöhnlichen Patch, aber bei einem Versions Update fast mit Sicherheit. Wenn ich davon ausgehe, das Systeme für eine Lebensdauer von ca. 4 Jahren geplant werden, haben Sie eine sehr reelle Chance für mindestens ein bis zwei große Updates mit ordentlicher Downtime.

Planen Sie also besser für mindestens zwei mal im Jahr ein Wochenende Downtime für Ihre Datenbank Systme ein. Wenn die nicht gebraucht werden, sind Ihre Kunden auch nicht sauer. Umgekehrt schon eher…

Können Sie grundsätzlich nicht auf Downtimes verzichten, benötigen Sie etwas anderes als RAC: eine Standby Database mit ORACLE Data Guard. Dann aber haben Sie trotzdem noch geringe Umschaltzeiten und wirklich alle DB Systeme doppelt.

Aber immerhin: für alle kleineren Patches braucht man mit Oracle RAC tatsächlich keine kompletten Downtimes der gesamten Architektur mehr.  Und nichts mehr oder weniger verspricht uns ORACLE hier.

Ach so – für Ihre Applikation sind Sie selber verantwortlich. Wenn dort neue Versionen Datenbank Änderungen benötigen, haben Sie schon wieder eine Gelegenheit für eine Downtime: aber natürlich nur für Ihre Anwendung – die DB läuft ja weiter …

Viele Grüße

Michael Zimmer

Hallo,

ZFS ist ja ein tolles Filesystem. Es hat Prüfsummen für jedes File und kann so feststellen, ob das File unbeschädigt und intakt ist. Bei Plattenspiegelung (mirror, RAID1) kann ZFS also feststellen, welche der Kopien die unbeschädigte ist. Im Gegensatz zu den alten Verfahren des Mirroring, wo nur sichergestellt werden kann, das die beiden Spiegel physikalisch mit den gleichen Daten versehen sind, ergibt das eine erheblich erhöhte Datensicherheit.

Um sicher zu stellen, das die Daten auf beiden Spiegeln intakt sind, gibt es den Befehl scrub. Das sollte man bei gespiegelten Filesystemen gelegentlich laufen lassen. Da es natürlich I/O intensiv ist, kann man immer nur einen Scrubbing Prozess laufen lassen, also keine parallele Verarbeitung.

zpool scrub [-s] pool

-s: stop

zpool scrub rpool

Das Scrubbing läuft im Hintergrund ab. Man kann sich mit zpool status den Fortschritt anzeigen lassen:

root@UDSSR:~# zpool status
pool: rpool
state: ONLINE
scrub: scrub in progress for 0h0m, 0.63% done, 0h28m to go
config:

NAME        STATE     READ WRITE CKSUM
rpool       ONLINE       0     0     0
mirror-0  ONLINE       0     0     0
c5d0s0  ONLINE       0     0     0
c5d1s0  ONLINE       0     0     0

errors: No known data errors

Bei preiswerten Platten sollte man etwa alle 2 Wochen einen Lauf starten. So bekommt man Plattenfehler rechtzeitig mit und kann ohne Datenverlust für Ersatz sogen. Wichtige Applikationen laufen sowieso auf Systemen mit robusteren Server Platten. Dort reicht es auch etwa alle zwei Monate einen Scrub Lauf zu starten.

Viele Grüße

Michael