Rund um Datenbanken

[Taffspeed]

Nachdem ich vor fast 10 Jahren das letzte mal was mit DBs gemacht habe (waren div. "Vergewaltigungen" mit MSSQL), kommt wohl demnächste eine richtige Datenbank (?!) von Oracle ins Haus und dazu und zu anderen Themen gibts eine menge Fragen

1. Ich möchte eine Oracle DB 11gR2 unter Linux installieren, welche Distribution verwendet man am Besten? Oracle Linux?
   
2. Da die Installationsanleitung auf oracle.com sehr detailiert ist (fast schon zu detailiert ist für die ersten Schritte), bin ich noch immer auf der Suche nach einer guten Anleitung für eine Standardinstallation, kennt jemand gute Anleitungen bzw. kann auch ein Buch dazu sein.
   
   • Folgende Anleitungen habe ich gefunden, aber keine Ahnung ob die auch gut sind?
     http://www.oraclefla...-on-RHEL-5.html
     http://www.oracle-ba...cle-linux-6.php
     

[*]Wie wird zZ der Zugriff auf die Datenbank über c++ aus? Verwendet man da noch immer Pro*C++ oder soll man OCCI verwenden?

[*]Kennt jemand das Verhalten, wenn man sehr viele Connections zu einer DB offen hat? Div. Connections sind quasi "idle"-Connections, erzeugt das eine zu hohe Grundlast oder ist das eher egal? Gibt es trotz CPU-Lizenz auch ein Connectionlimit?

[*]Kann man ein automatisches Zugriffsbalancing der connections machen, wenn der DB-Server zb. an zwei Backbones hängt?

Bin auf eure Antworten gespannt

DANKE.

[axeman]

1. SLES, RHEL, Oracle Linux - alles zertifiziert. ist eine geschmacks-/lizenzfrage

2. hast du den "quick installation guide" gesehen? an den kernelparametern, os-packages etc. wirst du nicht vorbeikommen. die installation selbst ist dann eh selbsterklärend.

3. darüber weiss ich zuwenig

4. definiere bitte "sehr viele connections" idle sessions erzeugen praktisch keine cpu-last. lizenztechnisch gibt es kein limit, die maximale anzahl wird per (modifizierbarem) init-parameter "processes" limitiert.

5. macht meiner meinung nach wenig sinn - was erwartest du dir davon?

ich hoffe du kannst mit der kurzfassung etwas anfangen.

[Taffspeed]

schen daung!

1) Wenn die wahl auf RHEL oder Oracle Linux fallen soll was soll man dann nehmen? Gibt es überhaupt einen Vorteil Oracle Linux RHEL vorzuziehen, da ja Oracle Linux quasi eh RHEL ist?

2) öha, dass habe ich wohl übersehen, wobei da werde ich dann doch noch bissl mehr lesen müssen damit ich total klar komme.

3) Ev. reicht ja das schon was du darüber weißt

4) Im Normalfall wird es zw. 5000-10.000 connetions geben und es könnte auch sein, dass wir wo in 12-18 Monaten 25.000 connections haben. Gerade so am Vormittag wird es connections geben die nichts tun und nicht geschlossen werden sollen, damit der open-connection prozess nicht zu lange aufhält.

5) Wir haben in unserem System 2 Backbones, wenn zb. ein switch eingeht, dass wir ein automatisch auf deM anderen Backbone alles abwickeln können bzw. wir das eh ständig schon tun, jedoch ist jeder Backbone groß genug, dass er auch alleine ausreicht.

[axeman]

bittschen, gerne!

1) mit oracle linux hab ich ehrlich gesagt noch nicht gearbeitet. aus technischer sicht mag der "unbreakable kernel" - kernelpatching ohne reboot - recht vernünftig klingen, aus nicht-technischer sicht der db- und os-support aus einer hand.

2) http://www.oracle.com/pls/db112/homepage stimmt schon, dass die doku äusserst umfangreich ist. aber ein vernünftiges DBMS ist schliesslich kein staubsauger mit ein/aus-schalter

3) kein kommentar

4) gut, "sehr viele" sind in diesem fall wirklich "sehr viele". bei dieser anzahl und der tatsache, dass viele sessions idlen, würde ich auf jeden fall zu einer shared server konfiguration raten. http://docs.oracle.com/cd/B28359_01/server.111/b28310/manproc001.htm sollte einiges erklären

5) d.h. die backbone-anbindung erfolgt über zwei getrennte interfaces, oder? in diesem fall kann man auf jedem interface einen listener laufen lassen und die clients entsprechend konfigurieren. bzgl. redundanz macht das natürlich sinn, bzgl loadbalancing eher weniger.

soweit zufrieden?

[Taffspeed]

soweit zufrieden?

mit deinen infos bin ich immer zufrieden danke!

aber leider ist mein wissen über das ganze so klein, gegenüber deinem wissen, dass ich da immer noch bissl blöd fragen muss

2) schade, ein datenstaubsauger wäre schon super

5) wenn ich das richtig deute, dann schaltet man einen shared server vor einen db-server, der das connection-handling macht (oder geht man dann davon aus, dass man sowieso mehrere db-server braucht, wenn es so viele connections gibt?

[axeman]

also bitte, unter blöd fragen verstehe ich etwas ganz anderes.

bei 5) liegst du allerdings falsch. das connection handling erledigt der listener. dedicated server heisst nix anderes, als dass für jeden clientprozess ein serverprozess (und damit ein os-prozess) gestartet wird. das ist auch die standardkonfiguration einer instanz. beim shared server - der extra konfiguriert werden muss - bedient ein serverprozess mehrere clientprozesse, die von einem dispatcher zugeteilt werden. macht natürlich bei deiner wirklich hohen anzahl an sessions, die noch dazu grossteils herumidlen, sinn.

ob ein oder mehrere db-server benötigt werden, hängt natürlich ganz stark von der workload ab, die bedient werden muss.

am datenstaubsauger arbeite ich noch

[Taffspeed]

aaaah das scheint schon logischer, DANKE für die infos!!!

[Taffspeed]

so muss diesen thread wieder mal ausgraben

gibt's wen der sich mit postgre beschäftigt?

ev. auch pgbouncer oder pgpool verwendet?

wie siehts aus mit der libpqxx, hat da auch einer einen ordentlichen überblick (bräuchte da eine asynchrone bzw. nonblockling lösung bei der abarbeitung von sql-requests)

[Evilken]

Frage:

Wie ists am gscheitesten, dass man Dateien und Dokumente in einer Datenbank speichert? Gäb ja die Möglichkeit über longtext mehr raufzuladen, da hab ich aber schon schlechtes über die zukünftige Performance gelesen. Gibts da noch irgendwas anderes gscheites?

[Taffspeed]

obwohl mein letzter post hier erst zwei jahre alt ist, komme ich mir vor als hätte ich gar keine ahnung mehr wie ein DB-design aussehen sollte

alsoooooo, ich habe folgedes problem: man hat quasi eine art tv-zeitschrift, epg, etc. und da kommen pro sender div. sendungen vor und eine sendung hat meistens was mit personen zu tun die in der sendung vorkommen, wie bildet man das bestens in einer DB ab?

vorschlag 1:

vorschlag 2: man spart sich div "hilfstabellen" und packt alles in eine tabelle und hat div. bools zum spezifizieren

vorschlag 3: ähnlich wie vorschlag2, jedoch hat man statt den bools quasi einen enum

aus der programmiersicht würde mir vorschlag 2 und 3 gefallen.

wie würdest ihr es machen? welche vor und nachteile würdet ihr in sachen performance sehen (häufige ausgabe der sendung inkl. aller personen, suche nach sendungen wo eine person dabei ist inkl. filterung auf den type)

thx.

bearbeitet 10. Dezember 2015 von Taffspeed

[Pimmi]

vorschlag eins ist schon sehr akademisch, wobei rein modellierungstechnisch würde ich sagen auch nicht ganz korrekt. wenn ich das richtig verstehe hast zu zwischen Person und Sendung eine Assoziationsentität, da die Eigenschaften prinzipiell mal existenzabhängig von den zwei Entitäten Person und Sednung sind (sprich das PersonSendung Kastel würde eigentlich an der Beziehung zw. Person und Sendung hängen und nicht dazwischen). Entsprechend würde ich zumindest wenn's ein OLTP ist die Rolle welche die Person einnimmt als Typ (bzw. Enum) verwenden und auf alle Fälle indizieren. Ansonst je nach Datenmenge/Datenbank mit Indizes, Partitionen, Optimizieren usw. arbeiten.

Allerdings komm ich ja mehr von der OLAP-Seite, da würd ich das sowieso denormalisieren

[churchill]

im prinzip würde ich es einfach so machen:

zwischen person und sendung würde ich mehrere beziehungen machen, wenn es mehrere rollen gibt. nimmt teil für gäste, produziert für produzenten, dann kann man die kardinalitäten kontrollieren.

btw gestern erst eine prüfung über data warehousing gehabt, da gerade oltp und olap erwähnt wurden

[StepDoWn]

obwohl mein letzter post hier erst zwei jahre alt ist, komme ich mir vor als hätte ich gar keine ahnung mehr wie ein DB-design aussehen sollte

alsoooooo, ich habe folgedes problem: man hat quasi eine art tv-zeitschrift, epg, etc. und da kommen pro sender div. sendungen vor und eine sendung hat meistens was mit personen zu tun die in der sendung vorkommen, wie bildet man das bestens in einer DB ab?

vorschlag 1:

erd1.png

vorschlag 2: man spart sich div "hilfstabellen" und packt alles in eine tabelle und hat div. bools zum spezifizieren

erd2.png

vorschlag 3: ähnlich wie vorschlag2, jedoch hat man statt den bools quasi einen enum

erd3.png

aus der programmiersicht würde mir vorschlag 2 und 3 gefallen.

wie würdest ihr es machen? welche vor und nachteile würdet ihr in sachen performance sehen (häufige ausgabe der sendung inkl. aller personen, suche nach sendungen wo eine person dabei ist inkl. filterung auf den type)

thx.

Stichwort Normalformen (der Wikipedia Artikel dazu ist empfehlenswert - einfach genug, aber zeigt die üblichen Probleme und Vor- und Nachteile etc auf).

Hab ganz flott gebastelt:

https://drive.google.com/file/d/0B7vVmPaCkFRRZVJFWk5QMU52WmM/view?usp=sharing

Liest sich so:

Ein Auftritt kann aus mehreren (einzelnen) Personen bestehen, eine Sendung aus mehreren (einzelnen) Auftritten. Der Auftritt wird weiter durch Rollen bezeichnet (keine Ahnung, Regisseur, Hauptrolle, Nebenrolle, ..?), der Table ist ein Beispiel für deine quasi enums.

Kann man jetzt natürlich ewig weiterspinnen, bzw was sich dann empfiehlt ist einfach mal Daten eingeben und zu schauen, ob alles Sinn macht bzw aufgeht. Oder ob man das eigene Modell zerschießen kann, bei meinem fällt mir zb gleich mal ein dass eine Person ja 2 Rollen haben kann (Regisseur + Hauptrolle), das würde mit meinem Modell schonmal nimmer gehen (müsste man PK von PersonId bei Auftritt wegnehmen und entsprechend eine eigene Auftritt-ID einführen).

Bezüglich Suche und Performanz: bei deinen "enum"-Tables ists relativ wurscht. Sauber ist natürlich eine int ID, die lässt sich logischerweise schneller abgleichen als ein string PK. Wenn bei "Rollen" 100 verschiedene Einträge sind ist das noch immer ziemlich tuttl, tendenziell sollte man aber natürlich sauber modellieren, irgendwann ist dann nämlich plötzlich ein Table mit ein paar Millionen Einträgen da, da ist schon das Filtern nach int ein hoher Aufwand. Als Faustregel kann man sagen bool > int > string, aber bei den meisten DB-Anwendungen ist das relativ egal.

@Churchill: solid paint skills, lernts ihr sowas auf der TU?

(Probier mal www.draw.io)

[Taffspeed]

vorschlag eins ist schon sehr akademisch, wobei rein modellierungstechnisch würde ich sagen auch nicht ganz korrekt.

hmm wie wärs korrekt?

im prinzip würde ich es einfach so machen:

ähm n:m beziehungen? also das gefällt mir in einer relationalen db eher weniger gut

außer die realtionalen dbs sind in deinen augen hier nicht zielführend?

Bei meinem fällt mir zb gleich mal ein dass eine Person ja 2 Rollen haben kann (Regisseur + Hauptrolle), das würde mit meinem Modell schonmal nimmer gehen (müsste man PK von PersonId bei Auftritt wegnehmen und entsprechend eine eigene Auftritt-ID einführen).

genau, eine person kann öfters vorkommen, aber mit einer anderen rolle (mittels enums würde ich hier in meiner nicht db-struktur eben die werte binär-verodern)

[churchill]

@Churchill: solid paint skills, lernts ihr sowas auf der TU?

(Probier mal www.draw.io)

also ob ich nix zum modellieren hab, paint ging aber am schnellsten