Oracle en drie vage dingen ?

[Vampy719]

Ik vraag me af hoe Orcacle de onder staande dingen oplost, ik ben er namelijk nog niet helemaal over uit over deze onderwerpen binnen DBMS. En kan er ook niks over vinden op de Oracle site zelf


1.Als een bepaald proces van een programma fout gaat, wordt dit proces “gekild” andere processen kunnen doorgaan. Wat is er met de bewerking van het “gekilde proces” gebeurt. Dit is onzeker en onduidelijk

2. Voor bescherming tegen een mogelijke systeemfout worden regelmatig (iedere dag, eigenlijk elke nacht) back-ups gemaakt. Dit op zich wordt als niet voldoende beschouwd, daar na een “crash” die acties van na de laatste back-up als verloren beschouwd moeten worden

3.Er zijn transacties die betrekking hebben op meerdere systemen. De controle hiervan goed op de orde krijgen vereist veel extra, lastig, programmeerwerk. Of is er iets speciaals voor ingebakken binnen Oracle


Misschien weten jullie iets en dan ben ik jullie daar erg dankbaar voor. Want ik tast nu volledig in het donker

[VisionMaster]

Vampy schreef op 12 november 2003 @ 12:04:
Ik vraag me af hoe Orcacle de onder staande dingen oplost, ik ben er namelijk nog niet helemaal over uit over deze onderwerpen binnen DBMS. En kan er ook niks over vinden op de Oracle site zelf

Oracle verklapt zijn geheimen niet. Dit mag toch wel redelijk duidelijk zijn. Je behoort over DBMS handelingen ook niet al te veel te hoeven te weten. Je moet er vertrouwen in hebben dat je SQL query goed wordt uitgevoerd. bijvoorbeeld dan ... het is erg algemeen verteld zo... maar weet het niet echt anders te vertellen...

1.Als een bepaald proces van een programma fout gaat, wordt dit proces “gekild” andere processen kunnen doorgaan. Wat is er met de bewerking van het “gekilde proces” gebeurt. Dit is onzeker en onduidelijk

Oracle (kan) logging bijhouden en dus van ieder proces bijhouden wat er daarin gebeurt is. Als je proces gekilled is en de handeling is gestopt kan de DBMS beslissen het nog eens te proberen. Dit is een beslissing van de DBMS en je zou alleen maar in de logs moeten kijken wat er gebeurt is en proberen te extraheren waarom iets mis zou zijn gegaan.

2. Voor bescherming tegen een mogelijke systeemfout worden regelmatig (iedere dag, eigenlijk elke nacht) back-ups gemaakt. Dit op zich wordt als niet voldoende beschouwd, daar na een “crash” die acties van na de laatste back-up als verloren beschouwd moeten worden

Uiteraard zal een systeemcrash je tot aan de laatste backup terug brengen. Simpel gezegd is het gewoon jammer voor je gegevens, maar helaas... Je had een systeemschaduw kunnen laten draaien, zodat twee machines redundant van elkaar zijn. Knalt er 1, dan over op de andere. Heb je een systeem error dan ligt het aan je systeem dat je moet onderhouden/redundant maken. Daar heeft Oracle weinig mee te maken.
Als je het heb over een proces, query afhandeling of dergelijke acties van Oracle... Tja dat ligt aan je config. Je kan op verschillende manieren vertellen aan Oracle hoe hij zijn transacties moet afhandelen. Bij een error... stop je dan... of probeer je het nog een keer. Op welke error doe je welke handeling ... dat soort dingen. Als er twee transacties dezelfde data wil lezen of schrijven, dan is dit maar net welke methode van transacties afhandeling er wordt gebruikt en of je wenst dat gegevens opnieuw in de scheduling queue worden geplaatst en dat het opnieuw uitgevoerd kan worden.

3.Er zijn transacties die betrekking hebben op meerdere systemen. De controle hiervan goed op de orde krijgen vereist veel extra, lastig, programmeerwerk. Of is er iets speciaals voor ingebakken binnen Oracle

Zijn dat transacties die ook met Oracle worden gedaan? Wat voor transacties zijn dit. Waar komen de gegevens bij elkaar (is het een gedistribueerde DB, of heb je meerdere losse DBs). Tis dus situatie afhankelijk. Met losse DBs ben je afhankelijk van je programmeerwerk. En tja ... niemand had ooit gedacht dat dit zo simpel moest zijn. Met een distri. DB kan je veel van je problemen naar Oracle verplaatsen. Die zou de koppelingen en data distributie voor zijn rekening kunnen nemen en dus er voor zorgen dat de gegevens consistent blijven over de sites. Je kijkt dan naar 1 'grote' Database.

Misschien weten jullie iets en dan ben ik jullie daar erg dankbaar voor. Want ik tast nu volledig in het donker

Ik hoop dat ik een licht heb aan gedaan?

[Vampy719]

Heee TOP bedankt voor het licht ( schijnwerper) En dan nu even de zelfte vragen alleen voor MYsql dbms opzoeken zodat ik kan zien wat de verschillen zijn van aanpak tussen de twee DBms-en Oracle & MYsql met die bovenstaande vragen !!!

Maar goed thnx zo ver kom een heel eind zo !!!

[Verwijderd]

Overigens kan je archive logging en point-in-time recovery met Oracle doen, zodat je theoretisch tot de seconde voor een crash of fatale transactie kan herstellen.

In hoeverre een "gekillde" transactie verwerkt is (ik denk dat je dat bedoelt), hangt af van de status. Maar daar kom je in een grijs gebied, heel veel is namelijk afhankelijk van de inrichting van je database en de soort opdracht of transactie die je uitvoert.

[SPee]

Ik denk dat je dit echt alleen moet afvragen in superkritische omgevingen of in superstressed omgevingen, zoals een web zoeksysteem.
Anders zijn dit niet echt superbelangrijke vragen.

Voor 2, je kunt ook een andere server met database maken en op elke actie een trigger zetten, die hetzelfde uitvoert op de andere server.

[VisionMaster]

Vampy schreef op 12 november 2003 @ 13:34:
Heee TOP bedankt voor het licht ( schijnwerper) En dan nu even de zelfte vragen alleen voor MYsql dbms opzoeken zodat ik kan zien wat de verschillen zijn van aanpak tussen de twee DBms-en Oracle & MYsql met die bovenstaande vragen !!!

Maar goed thnx zo ver kom een heel eind zo !!!

Uhm ... waar heb je deze paranoide informatie voor nodig.
Je vraagt eigenlijk naar een vergelijking van de DBs in een worst-case senario.
Naar welke verschillen ben je opzoek?

[Vampy719]

Het gaat mij er om, om te achter halen hoe de drie boven staande worst-case senario's worden afgehandelt bij Oracle en MYsql dmbs omzo de verschillen te achter halen van aanpak.

Snap je me nog

[VisionMaster]

Vampy schreef op 12 november 2003 @ 14:34:
Het gaat mij er om, om te achter halen hoe de drie boven staande worst-case senario's worden afgehandelt bij Oracle en MYsql dmbs omzo de verschillen te achter halen van aanpak.

Snap je me nog

Ik begrijp je wel, maar je heb nog niet uitgelegd wat je doel is. Is dit personal knowledge of is dit voor een bedrijfsquestie.
MySQL pakt een hele zwik zaken op een andere manier aan. Tot zo ver ik nu zie een niet al te veel minder aanpak dan Oracle.
Ik wil zo graag weten waarom je het wil weten, zodat ik een gerichter antwoord kan geven. Ik kan wel 20 pagina's vol tikken

[Vampy719]

We hebben een discusie en ik moet het een docent dus uitleggen. Wat zijn de verschillen van aanpak en wat is beter. Dus een Deskundig advise uitbrengen op het feit van de DRIE vragen, jah het is allemaal beetje vaag vandaar dat ik hier bij jullie terecht kom

[VisionMaster]

Vampy schreef op 12 november 2003 @ 22:42:
We hebben een discusie en ik moet het een docent dus uitleggen. Wat zijn de verschillen van aanpak en wat is beter. Dus een Deskundig advise uitbrengen op het feit van de DRIE vragen, jah het is allemaal beetje vaag vandaar dat ik hier bij jullie terecht kom

Ok ... had je best mogen melden ... ik dacht dat je een paranoide sysadmin was die wilde weten hoe zijn spul nu echt in elkaar zit.

Maar goed ... dan maar even vlug MySQL dan maar... anders krijg je je antwoorden nooit.

Vampy schreef op 12 november 2003 @ 12:04:
Ik vraag me af hoe Orcacle de onder staande dingen oplost, ik ben er namelijk nog niet helemaal over uit over deze onderwerpen binnen DBMS. En kan er ook niks over vinden op de Oracle site zelf

Als je ECHT wil, kan je de sources van MySQL bekijken.

1.Als een bepaald proces van een programma fout gaat, wordt dit proces “gekild” andere processen kunnen doorgaan. Wat is er met de bewerking van het “gekilde proces” gebeurt. Dit is onzeker en onduidelijk

Zie Oracle... maar bij MySQL is het iets eenvoudiger. De MySQLd (d= daemon) forked zichzelf voor het afhandelen van een netwerkverbinding. Alle verbindingen zijn netwerkverbindingen voor MySQL (voor Oracle ook trouwens, maar goed...).
Crash je prog, dan hangt je transactie of je query. MYSQLd wacht tot de time-out tijd is verstreken (idem voor Oracle) en dan gooit het de transactie de prullenbak in. En je krijgt doorgaans Oracle en MySQL een abort. Je kan dit instellen! Maar zou het je niet aanraden dit te veranderen.

2. Voor bescherming tegen een mogelijke systeemfout worden regelmatig (iedere dag, eigenlijk elke nacht) back-ups gemaakt. Dit op zich wordt als niet voldoende beschouwd, daar na een “crash” die acties van na de laatste back-up als verloren beschouwd moeten worden

Zoals al eerder verteld kan Oracle naar je laast state terug gaan en daar verdergaan met excecutie van de transacties. Kan handig zijn, ik gebruik het nooit. Bij MySQL is deze functie niet aanwezig. Killed is killed. En als je transactie halverwege was, jammer. Voor beide geld dat je wel een fysieke kopie moet hebben om het te restoren. Voor MySQL geld dan vaker backuppen, al is dat niet praktisch. MySQL kan je natuurlijk ook als schaduw draaiende DB laten lopen, maar naar mijn weten heb je 3rd-Party software nodig.
Bij Oracle is dat een minder probleem. Al is het natuurlijk zo, dat als je geen schaduw systeem heb, dat je zowisso met de DB(MS) in actie altijd 'iets' kwijt raakt. Oracle heeft een goede reputatie, maar valt en/of staat bij een stabiel en werkend systeem.

3.Er zijn transacties die betrekking hebben op meerdere systemen. De controle hiervan goed op de orde krijgen vereist veel extra, lastig, programmeerwerk. Of is er iets speciaals voor ingebakken binnen Oracle

Oracle kan hier native tussen andere Oracles werken. Met andere DB moet er ook een hoop mogelijk zijn. Maar bij MySQL is het niet mogelijk zonder om programmeren. Search op www.google.com op het trefwoord 'R-GMA' van het EU DataGrid project. Dat is een omgebouwde MySQL die een gedistribueerde database voorstelt. Je praat ertegen alsof het 1 database is, maar in feite is het info van 10+ sites en dit worden er 100+ sites.
Het werkt nog niet lekker, maar dat komt nog wel

Oracle en samen werken met andere DBMS-en wil niet altijd vlekken loos gaan. Het is eenvoudiger om het ruim te programmeren.
Als ik wat in elkaar prog, dan maak ik koppelingen naar verschillende DB vanuit 1 applicatie. En binnen de App kan ik dan mijn gegevens overspugen. Liefst allemaal ODBC, dan heb je iig dezelfde koppelingstypen vanuit je programma.

Nog meer licht nog ?

[Verwijderd]

Vampy schreef op 12 november 2003 @ 12:04:
En kan er ook niks over vinden op de Oracle site zelf

Heb je ook op Oracle Technology Network gekeken? Site vraagt wat gewenning maar staat een schat aan informatie op, waaronder heel gedetailleerde technische informatie.

[TheekAzzaBreek]

1.Als een bepaald proces van een programma fout gaat, wordt dit proces “gekild” andere processen kunnen doorgaan. Wat is er met de bewerking van het “gekilde proces” gebeurt. Dit is onzeker en onduidelijk

Dit hangt af van het soort van fout, en het soort van proces.

Fout:
- als het een SQL error is - en je bent niet te lui geweest om er een handler voor te schrijven - kan je programma gewoon doorgaan, maar dat is afhankelijk van je eigen programma.
- als het een crash is, van jouw proces of iets binnen het RDBMS, wordt het process gekilled, en de activiteit tot het laatste commit statement teruggerold.
- als het een deadlock is beslist het RDBMS welke van de twee processen gekilled wordt, en dus ook netjes teruggerold.

Proces:
- als je programma zelf expliciet meerder threads start, en iedere thread een eigen transactie start, kan bij een crash van een thread de rest gewoon doorspelen.
- als het RDBMS zelf heeft bedacht een actie in meerdere threads te splitsen zijn die allemaal onderdeel van dezelfde transactie, en gaan dus per definitie allemaal goed of allemaal fout.

2. Voor bescherming tegen een mogelijke systeemfout worden regelmatig (iedere dag, eigenlijk elke nacht) back-ups gemaakt. Dit op zich wordt als niet voldoende beschouwd, daar na een “crash” die acties van na de laatste back-up als verloren beschouwd moeten worden

Als je de DB vertelt dattie alle logs moet bewaren (archive-log mode) kan je na een restore alle acties uit de logs tot een op te geven tijdstip opnieuw uitvoeren. Als er geen restore nodig is zal hij zelf alle nog niet fysiek weggeschreven data automagisch wegschrijven tijdens startup. Geen problem, dus.

(@visionmaster: Oracle garandeerd pas vanaf versie 9iR3 dat alles ook in de logs terecht komt, voor die tijd alleen dat alle uitkomsten van transacties er te vinden zijn. B.v. een insert-update-delete-commit van een enkele rij levert geen data in het log op)

3.Er zijn transacties die betrekking hebben op meerdere systemen. De controle hiervan goed op de orde krijgen vereist veel extra, lastig, programmeerwerk. Of is er iets speciaals voor ingebakken binnen Oracle

Yep, dat heet two-faced commit. Je kan dus iets schrijven als "update tabel_a, tabel_b@database_op_mars" en de DB zorgt er voor dat beide updates lukken, of als er eentje fout gaat de ander ook teruggedraaid wordt.

Als je MySql met Oracle wil vergelijken ben je nog wel even zoet, maar m.i. het meest fundamentele verschil is dat Oracle zich volledig transactioneel gedraagt. Bij MySql is dat een recente add-on, waarbij je in je code die transactie-API moet aanroepen, een beetje zoals dat in de 70's in pre-relationele databases ging. NFI

[VisionMaster]

TheekAzzaBreek schreef op 13 november 2003 @ 13:53:
Intelli. blaat

Oracle 9i ?
Hmmm ok ik weet van een Oracle 8.x.x.x versie dat die dat ook (veel) deed.
Dus die garantie is ook pas nieuw, weer wat geleerd. Bij MySQL is het idd gewoon simpelere/net pas opgezet.
Het transactie gebeuren met MySQL is nog wel flink in ontwikkeling. MySQL kan nog wel een grote DB op de markt worden. Maar dan zullen ze de komende 5 jaar nog even flink aan de weg en zichzelf moeten timmeren.
Hoe verloopt je Discu. met die docent?
* VisionMaster vind het altijd leuk om discussies aan te gaan met docenten en te ontdekken wat de limits zijn van de docent.

offtopic:
Kwil er nog even aan toevoegen dat dit niet een MySQL vs. Oracle topic moet gaan worden. Das namelijk een gebed zonder eind, 'been done' en een beetje nutteloos.

[ Voor 13% gewijzigd door VisionMaster op 13-11-2003 15:17 ]

[whoami]

Ivm puntje 3, die transactie's die over meerdere systemen gespreid zijn:

Doe je dit niet best via een TransactionManager, met behulp van COM+ bv ?
De transactie wordt dan beheerd door die transaction-manager, en de verschillende processen laten weten of ze hun gegevens willen 'committen' of 'aborten'. Indien ieder proces binnen die transactie een 'commit' stuurt, dan worden de gegevens gecommit, indien echter 1 van die processen een 'abort' stuurt, dan wordt de transactie gerollbacked.

[Vampy719]

AAHAHAH mensen heel erg bedankt ik lul die docent helemaal plat Er is me een heleboel duidelijk geworden. NOG MAALS Thnx

Ik ga er een verslag van maken met jullie hulp

groeten !!!!vampy

[TheekAzzaBreek]

VisionMaster schreef op 13 november 2003 @ 15:16:
[...]

Oracle 9i ?
Hmmm ok ik weet van een Oracle 8.x.x.x versie dat die dat ook (veel) deed.
Dus die garantie is ook pas nieuw, weer wat geleerd. Bij MySQL is het idd gewoon simpelere/net pas opgezet.
[/offtopic]

Ja, heel nieuw, en errug handig. Je kan nu DB's synchroniseren vanuit de logs, of data extraheren (heel leuk voor mijn tak van sport, data warehousing). Oracle is hier idd traag mee, andere grote DB's hadden dat al jaren.

De-mijne-is-beter discussies zijn hier idd nog zinlozer dan anders, MySql en Oracle zijn voor totaal andere doelen geschikt. Je gaat geen 10 tonner inzetten waar een pickup truck volstaat, of andersom. MySql speert als een mostly-query DB, Oracle (of DB2, SighBase etc) is meer geschikt voor (heel) groot of kritisch.

[TheekAzzaBreek]

whoami schreef op 13 november 2003 @ 15:37:
Ivm puntje 3, die transactie's die over meerdere systemen gespreid zijn:

Doe je dit niet best via een TransactionManager, met behulp van COM+ bv ?
De transactie wordt dan beheerd door die transaction-manager, en de verschillende processen laten weten of ze hun gegevens willen 'committen' of 'aborten'. Indien ieder proces binnen die transactie een 'commit' stuurt, dan worden de gegevens gecommit, indien echter 1 van die processen een 'abort' stuurt, dan wordt de transactie gerollbacked.

Dat kan heel goed. Het moet zelfs zo als de DB's verschillend zijn. Als alles Oracle is zou ik de Oracle methode gebruiken: makkelijk in code, en een stuk sneller. Sommige Transactie Managers kunnen zelf omgaan met offline DB's: de hele transactie wordt dan in de wacht gezet tot alles weer online is. In wereldwijde systemen met verschillende backup tijden en allerlei kwetsbaarheden kan dat je een hoop ellende schelen. Het is hetzelfde soort discussie als ODBC/JDBC vs native: xDBC geeft je flexibilteit, maar kost je mogelijkheden en snelheid, en je zit met een extra component die stuk kan gaan. Van geval tot geval bekijken, dus.