c # - Sådan oprettes flere Oracle-databaser (skemaer) med den samme bruger?

Indlæg af Hanne Mølgaard Plasc

Problem



Vores firma ervervet noget software, der kører på C # Visual Studio 2010, Windows 7 og Oracle 11g. Efter lidt indsats fik vi softwaren til at fungere og fik en stabil database (skema) oprettet.


Vi starter nu processen med at migrere nogle data fra et gammelt system til dette 'nye' system. Jeg ønsker dog ikke at rydde op på vores arbejdsskema, da jeg forventer, at en smule forsøg og fejl vil blive nødvendige med vores dataimport.


Jeg ønskede at gøre følgende:
Lad os sige, at vores eksisterende skema hedder PROD. Jeg ønskede at oprette et andet skema kaldet TEST, som vi kan bruge til de importerede data. Derefter kan jeg i C # -koden bare skifte navnet på datakilden, når vi skifter mellem vores to database skemaer. Fangsten er, at brugernavnet og adgangskoden til denne forbindelse vises på en række steder spredt i koden. For at undgå at ændre brugeroplysninger på flere steder hver gang vi skifter mellem 'db-miljøer', ønskede jeg at oprette en enkelt bruger at have adgang til PROD og at TEST.


Hvordan kan man dog give brugerrettigheder til et specifikt skema? antyder dette er ikke muligt. Korrekt måde at give brugerne adgang til yderligere skemaer i Oracle foreslår en metode til at give adgang på et objektniveau, men dette er utilstrækkeligt: ​​ Jeg ønsker stort set, at en enkelt bruger har adgang til to identiske skemaer (PROD og TEST) . Når jeg har opnået dette, vil jeg begynde at ændre TEST til at starte med vores dataimport.


Jeg har også forsøgt at oprette TEST som en separat Oracle Database-installation på en anden port, men når jeg forsøger at oprette min bruger på denne nye instans, får jeg stadig en konflikt, som brugeren allerede eksisterer (da den blev oprettet for PROD i den oprindelige databaseinstallation ).


Min bruger eksisterer allerede og har adgang til PROD. Hvordan giver jeg ham også adgang til TEST? Eller hvordan kan man løse det mere generelle problem med at have en PROD og TEST-database defineret i en applikation, der bruger Oracle?


I MySQL ville dette være trivielt, men jeg har ingen ide om, hvordan man gør dette i Oracle. Jeg er meget ny til Oracle.

Bedste reference


Spørgsmålet om at give tilladelser er allerede blevet besvaret.


Nu til dit spørgsmål som helhed: Er jeg korrekt at læse, at du vil opdatere databaseskemaet, men du vil beholde det i samme database som et andet skema og køre både i hvad der ser ud til at være en produktionsdatabase? Hvis ja, læs det igen for at lade det synke i, hvor ekstremt farligt det er.


Når migrering fra et 'skema' til en anden, som en softwareopdatering, er det sikrere at oprette en ny database og migrere dataene. Dette giver dig masser af skud, da du kan blæse den nye database væk som du tilpasser scripts.


Hvis du vil have så lidt friktion som muligt i din software, skal du gøre et par ting:



  1. Reflekter koden fra moronen, der besluttede at oprette hardkodforbindelsesoplysninger på flere steder. Du skal hente strengene på ét sted, og sørg for at du ekstraherer DAL-kode (Data Access layer) til sin egen klasse.

  2. Overvej at oprette domæneobjekter, der ikke er afhængige af databaseskemaer. Jeg anser dette obligatorisk, men du kunne komme væk uden at gøre dette. Jeg vil stadig oprette domæneobjekter, selvom de matcher PROD-skematabellerne, da du ikke skal bruge datakonstruktioner, hvis du flytter fra et skema til et andet.

  3. Opret en grænseflade til dit dataadgangslag (DAL)

  4. Kort det aktuelle datasæt, gennem den aktuelle DAL, til domæneobjekterne, ved hjælp af grænsefladen.

  5. Kort det nye skema, via en ny DAL, til domæneobjekterne, ved hjælp af grænsefladen.

  6. Opret en fabrik (eller brug udbydermønsteret) for at bestemme hvilken DAL-objekt du skal bruge (dette gør applikationen konfigurerbar til gammelt eller nyt 'skema'


Andre referencer 1


Jeg antager, at du har et skema PROD og en DBUSER, som har nogle privilegier til objekter i dette skema.

DBUSER 's navn og kodeord er hardcoded over hele applikationen.

Du har oprettet et nyt skema TEST, som ser ud som PROD (inklusive tilskud til DBUSER).

Du vil have det, hvor applikationen gør noget:


UPDATE some\_table set ...


Det vil opdatere some\_table tabellen i TEST og ikke i PROD.

Mit forslag er at bruge og ændre SYNONYMER, dvs.-

Når du vil opdatere some\_table i PROD, gør: [17]


CREATE OR REPLACE PUBLIC SYNONYM some\_table for prod.some\_table;


og når du vil opdatere some\_table i TEST, gør:


CREATE OR REPLACE PUBLIC SYNONYM some\_table for test.some\_table;

Andre referencer 2


Forbindelsen til Oracle håndteres ikke korrekt i C # -koden, og det er det der forårsager problemer.


Hvis Data Access Layer blev defineret separat som Gregory foreslår, eller hvis en mere generisk navngivningskonvention blev brugt i SQL-sætninger som A.Bs svarpunkter til, ville det være meget enklere at skifte mellem to databaser.


Da vores mandat i øjeblikket ikke indebærer at foretage nogen ændringer/refactoring af kode, bruger jeg en backup og opsving tilgang:


Jeg opretter en sikkerhedskopi af arbejdsdatabasen. Så gør jeg de nødvendige tests og ændringer i databasen. Hvis jeg skal tilbage til arbejdsdatabasen, opretter jeg en sikkerhedskopi af 'test' -databasen igen og gendanner den oprindelige arbejdsdatabase ved hjælp af det relevante flag for at erstatte eksisterende tabeller i tilfælde af en gendannelse. Dette gør det muligt for mig at skifte frem og tilbage mellem 'work' -databasen og 'test' -databasen.


Dette er ikke ideelt, da det tager lidt tid at udføre sikkerhedskopier og genopretter, men fungerer uden at påvirke C # -koden og giver mulighed for at arbejde på en 'test' -database uden at påvirke den aktive. Da dette er et midlertidigt scenario, indtil databasen 'test' fungerer, er det den fremgangsmåde jeg følger.


Som de andre svar påpeger - er der et mere generisk behov for at rette/refactor/generalisere forbindelseskoden - jeg tror det er den bedste tilgang, og den eneste grund til at jeg ikke gør det med det samme er, at vi endnu ikke har mandat til at ændre koden.