Oracles indbyggede løsning på dette problem er ikke kryptering, men adgangskontrol ved hjælp af Database Vault eller Virtual Private Database for at forhindre henholdsvis DBA eller andre brugere i at se dataene, og Transparent Data Encryption for at kryptere data i hvile (OS/fil -niveau kryptering). Dette forhindrer ikke kun DBA i at se dataene, men også i at ændre dem eller slette dem.
Hvis du alligevel ønsker at kryptere dataværdierne, så skal al kryptering/dekryptering og nøglehåndtering håndteres eksternt fra databasen, hvor DBA ikke har adgang til krypteringsnøglerne. Hvordan det fungerer, afhænger af dit applikationsdesign og valg af programmeringssprog. Vær opmærksom på, at det ikke er at bygge en robust kryptering og nøgleadministrationsarkitektur en triviel øvelse...
Vær også opmærksom på, at indpakning af PL/SQL-kildekode kun er tilsløring af koden og ikke kryptering. Det kan let være vendes ved hjælp af et vilkårligt antal eksisterende websteder eller interne lagrede procedurer. En ægte DBA ville også have execute any procedure privilegium eller være i stand til at give sig selv eksplicit tilladelse til at udføre enhver dekrypteringsfunktion og ikke engang være ligeglad med, hvad nøglen var (kun Database Vault kunne forhindre dette).
At overføre nøglen til funktionen som input i stedet for at indlejre den direkte i koden ville også være problematisk, da DBA kan se din SQL på en række forskellige måder. Når den overføres via SQL-forespørgsel, kan nøglen også blive vist i ADDM-rapporter, databasesporingsfiler eller revisionssporet.
Der er ingen sikker måde at håndtere krypteringen på, som du beskriver med PL/SQL, der også beskytter dataene fra DBA.