[Oracle] - DB instance laten verwijzen naar andere datafiles

[Cavalera125]

Hoi,

ik zit met de volgende situatie:

• Om te ontwikkelen willen we dat iedere developer bij ons een lokale Oracle instantie draait met een user schema dat project specifiek is. Per klant een apart schema.
• Laten we even aannemen dat deze user 'main_project' heet. main_project heeft een 100 tabellen en 50 packages met stored procedures.
• Het komt natuurlijk voor dat een developer een week werkt aan project A en de week erna aan project B. We willen dan het juiste schema uit subversion halen en importeren o.i.d.

Nu wil ik er op een of andere manier voor zorgen dat een ontwikkelaar meerdere klant specifieke database schemas op zijn werkomgeving kan hebben. De username voor het database schema is voor al onze klanten hetzelde, zeg main_project. Is het bijvoorbeeld mogelijk om een symbolic link (junction in windows) te maken en die naar de datafiles te laten wijzen?

Dan zou de procedure voor het wisselen van klant / project het volgende zijn:

1. Stop database
2. Laat directory met datafiles verwijzen naar een andere directory met datafiles door middel van een junction.
3. Start database

Heeft iemand hier ervaring mee? Zijn er wellicht andere ideeen om dit te bereiken?

[The Eagle]

Waarom een lokale DB per developer? Zo zien ze niet wat een ander gemaakt hebben. Ik zou per klant gewoon een centrale OTAP-straat neerzetten. Net zo makkelijk en je zit niet met het switchen; men kan immers bij het aanloggen kiezen op welke DB men gaat werken

[justmental]

Naast de manier van werken die The Eagle al aankaart moet je je ook afvragen waar en waarom je een afhankelijkheid op database schema naam hebt.
Wat gaat er mis als ontwikkelaars het spul in een eigen gekozen schema installeren?

[Cavalera125]

The Eagle schreef op donderdag 02 juli 2009 @ 13:34:
Waarom een lokale DB per developer? Zo zien ze niet wat een ander gemaakt hebben. Ik zou per klant gewoon een centrale OTAP-straat neerzetten. Net zo makkelijk en je zit niet met het switchen; men kan immers bij het aanloggen kiezen op welke DB men gaat werken

We hebben een OTAP straat per klant en gebruiken dus op dit moment een centrale DB. Het nadeel van een centrale DB is dat als er 2 man aan dezelfde stored procedure werken ze elkaars wijzigingen kunnen overschrijven. Ik zie dit zeg maar hetzelfde als dat je met 2 man tegelijk in eenzelfde centraal geplaatste java source file gaat typen.

Onder andere deze link http://odetocode.com/Blog...ive/2008/01/30/11702.aspx heeft ons ertoe gezet om van de centrale DB af te stappen en een lokale DB per developer te gebruiken. Je zit elkaar dan niet in de weg. Periodiek (elke dag bijvoorbeeld) haal je updates (patchscripts bijvoorbeeld) van andere developers uit een svn repository en deze speel je in op je lokale DB zodat je up to date blijft.

justmental schreef op donderdag 02 juli 2009 @ 13:38:
Naast de manier van werken die The Eagle al aankaart moet je je ook afvragen waar en waarom je een afhankelijkheid op database schema naam hebt.
Wat gaat er mis als ontwikkelaars het spul in een eigen gekozen schema installeren?

Dat zou opzich een optie zijn alleen het brengt extra werk met zich mee met name door het updaten van synoniemen en uitdelen van grants, deze verwijzen namelijk naar andere schema's. Hier hebben we wel scripts voor, maar brengt dus extra werk met zich mee.

Ik heb net zelf even getest met junctions. Ik heb de datafiles met een junction naar een andere map laten wijzen. De datafiles gekopieerd en in de gekopieerde datafiles een schema verwijderd. Dit werkt, op deze manier kan ik dus bovengenoemde procedure uitvoeren:

1. Stop database
2. Laat directory met datafiles verwijzen naar een andere directory met datafiles door middel van een junction.
3. Start database

Het nadeel hiervan is dat je enorm veel overhead hebt wat betreft diskgebruik. De sysaux, system en undo tablespaces worden op deze manier voor iedere klant separaat opgeslagen.

Voor nu zijn er dus 2 opties:

1. Met junctions de verwijzing naar de datafiles aanpassen.
2. Per klant / project een unieke schemanaam gebruiken.

Zijn er nog andere ideeen?

[The Eagle]

Het principe van een OTAP en hoe daarmee omgesprongen moet worden is mij bekend. Ben zelf ERP-consultant, hak al jaren met dat bijltje

Ik denk dat je eens naar een stuk software als bijvoorbeeld STAT (van Quest) moet kijken. Wat dat feitelijk doet is objecten die in de DB staan inlezen en locken. Mist goed ingericht, kan maar 1 enkel persoon aan het zelfde object werken. En ja, dan gaan developers ineens zeuren dat ze elkaar in de weg liggen - maar da's een kwestie van gewenning en goede taakverdeling. Ze kunnen immers ook prima objecten (tijdelijk) aan elkaar overgeven. Aan het einde van het developmenttraject zet je alle objecten die in je ticket gelockt zijn over naar een andere DB ter test. Daarbij is het leuke van STAT dat het ook terug kan (ivm backups enzo), door de OTAP straat heen.
Ander voordeel: het kan ook met diverse schema's werken.

[Cavalera125]

Bedankt voor het meedenken, ik heb de demo video even bekeken. Wij gebruiken echter geen Oracle E-Business of PeopleSoft, alleen de Oracle database zelf. Ik kon zo snel even niet vinden of STAT dan bruikbaar is voor ons. Gebruik jij dit in de praktijk? Hoe zorgen jullie er voor dat developers elkaars wijzigingen niet overschrijven?

Opzich is het een mooie tool, maar toch geeft het beperkingen waar je volgens mij makkelijk omheen kan. Met name het locken van een object staat mij een beetje tegen. Wij gebruiken voor onze java source code subversion voor het versie beheer. Hier wordt een file niet gelockt als je er iets in gaat aanpassen. Ik zie dit als een voordeel, het geeft meer flexibileit en toch voldoende controle door de conflicts die subversion geeft als je met 2 man in dezelfde file gewerkt hebt.

Wij willen database objecten, en dan gaat het met name om packages, stored procedures e.d. hetzelfde gaan behandelen als onze java source code. Vandaar dus ook een lokale development database. Als je aan een java project gaat werken haal je immers ook eerst de code uit de svn repository naar je lokale werkomgeving. Vanuit de lokale development database kunnen de wijzigingen de svn repository in en dan vervolgens de OTAP straat in. Eigenlijk willen we dus naar een soort LOTAP

Maar goed, waar het dus in principe om gaat is dat we op een makkelijke manier op een lokale werkomgeving meerdere database schema's naast elkaar kunnen gebruiken. De schemas hoeven niet tegelijk te benaderen zijn overigens.