Using Oracle Scheduler to run SQL*Plus and RMAN scripts from PL/SQL

Transcription

1

2 Using Oracle Scheduler to run SQL*Plus and RMAN scripts from PL/SQL Bryn Llewellyn DisNnguished Product Manager Database Division Oracle HQ Fall 2014

3 Safe Harbor Statement The following is intended to outline our general product direcnon. It is intended for informanon purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or funcnonality, and should not be relied upon in making purchasing decisions. The development, release, and Nming of any features or funcnonality described for Oracle s products remains at the sole discrenon of Oracle.

4 Agenda The problem The historical approach The new approach, using DBMS_Scheduler Caveat: not quite ready for prime Nme in a CDB Conclusion

5 The problem Safely store a collecnon of SQL*Plus scripts and RMAN scripts Run them as needed maybe as cron jobs Hide the database user s passwords from prying eyes Hide the text of the scripts from prying eyes

6 Agenda The problem The historical approach The new approach, using DBMS_Scheduler Caveat: not quite ready for prime Nme in a CDB Conclusion

7 The historical approach Store the scripts as ordinary files on the same filesystem as the database s files, owned by a dedicated o/s user Run them using o/s authenncanon, without explicit use of a password I.e. the keys to the safe are represented by the password of the o/s user, which never needs to be stored Use o/s features to ensure that only the owner can read and change the scripts

8 Agenda The problem The historical approach The new approach, using DBMS_Scheduler Caveat: not quite ready for prime Nme in a CDB Conclusion

9 The new approach, using DBMS_Scheduler Retrieve the scripts from inside the database Stored directly in the source text of a PL/SQL unit Stored in a table that is read by a PL/SQL unit Generated on the fly by PL/SQL Use DBMS_Scheduler s new script job type to invoke sqlplus, or rman, and pass the script from the database to the tool The tool is started from a spawned o/s session, authorized as a low- privileged user, username and password stored in a o/s credennal in the database The tool connects to the database using the database username, password, and opnonal role stored in connect credennal in the database in the PDB that called the scheduler

10 Here it is in pictures

11 SGA

12 my SQL*Plus SGA my foreground

13 my SQL*Plus SGA my foreground

14 my SQL*Plus SGA my foreground

15 my SQL*Plus spawned SQL*Plus SGA my foreground

16 my SQL*Plus spawned SQL*Plus SGA my foreground spawned foreground

17 my SQL*Plus spawned SQL*Plus SGA my foreground spawned foreground

18 my SQL*Plus spawned SQL*Plus SGA my foreground spawned foreground Copyright 2014, Oracle and/or its affiliates. All rights reserved.

19 my SQL*Plus spawned SQL*Plus SGA my foreground spawned foreground

20 my SQL*Plus SGA my foreground

21 my SQL*Plus SGA my foreground

22 my SQL*Plus SGA my foreground

23 Here it is in code

24 Define the script in this example in the SQL*Plus language declare Slash constant char(1) not null := '/'; My_Script constant varchar2(32767) not null := ' WHENEVER SQLERROR EXIT SET SERVEROUTPUT ON SET LINESIZE 200 SPOOL Hello.txt begin DBMS_Output.Put_Line(''Hello World''); end; ' Slash ' SPOOL OFF '; begin... Text is text. You can simply write it out like this. Or get it from a table. Or generate it.

25 Create the o/s logon credennal Sys.DBMS_Credential.Create_Credential( Credential_Name => 'OS_CREDENTIAL', Username => 'joe_no_privleges', Password => 'not_very_secret', Enabled => true);

26 Create the Scheduler job Sys.DBMS_Scheduler.Create_Job( Job_Name => 'MY_JOB', Job_Type => 'SQL_SCRIPT', job_action => My_Script, Number_Of_Arguments => 0, Credential_Name => 'OS_CREDENTIAL', Enabled => false); The 'SQL_SCRIPT' job type is new in Oracle Database 12c. It spawns sqlplus The other new job type is BACKUP_SCRIPT. It spawns rman

27 Create the database connecnon credennal Sys.DBMS_Credential.Create_Credential( Credential_Name => 'DB_CREDENTIAL', Username => 'SYS', Password => 'oracle', Database_Role => 'SYSDBA', Enabled => true); - - OpNonal. Use with caunon! Associate the database connecnon credennal with the job Sys.DBMS_Scheduler.Set_Attribute( Name => 'MY_JOB', Attribute => 'CONNECT_CREDENTIAL_NAME', Value => 'DB_CREDENTIAL');

28 Run the job in the current session Sys.DBMS_Scheduler.Run_Job( Job_Name => 'MY_JOB', Use_Current_Session => true); The point of execunon gets here when the SQL*Plus script has finished, with or without error Drop the job it was a one- off Sys.DBMS_Scheduler.Drop_Job( Job_Name => 'MY_JOB', Force => true);

29 Agenda The problem The historical approach The new approach, using DBMS_Scheduler Caveat: not quite ready for prime Nme in a CDB Conclusion

30 How is it meant to work in a PDB? NoNce that the database credennal allows specificanon only of username, password, and role (supposedly) not listener locanon and service The intennon was that Oracle would nonce the origin container, and generate a connect string for sqplus to automancally reflect you back to that This simply was forgoken. I nonced it when preparing these slides for OpenWorld Embarrassing, eh... bug # In a CDB, right now, the spawned sqlplus and rmanjobs offer up the specified database credennal to start a session in CDB$Root The engineers are working to correct this trivial oversight

31 Workaround It turns out that the actual for the Password formal for allows a string like this: oracle@my_host:1522/r12102 This is probably freedom is its own bug. But it will be changed only as part of the fix for the main bug. So, in 12.1 (pre- patch), it provides an acceptable workaround

32 A further issue for running RMAN scripts It seem that if a value is provided for the Database_Role formal for DBMS_Creden@al.Create_Creden@al(), then the spawned rman program fails to connect. The only viable opnon seems to be to specify the Sys username and password and not to provide a value for Database_Role. This is enough to for a proof of concept, and you can familiarize yourself with the approach immediately

33 Packaging the code for re- use All the code I showed you, except to create the database credennal, is in an authid Current_User package, owned by a dedicated local user in the PDB It has only these System privileges: Create Session, Unlimited Tablespace, Create Table, Create Procedure, Create Credential

34 Serng up a client of my code This local user will create the logon credennal using the username and password that are used to create a session to do the creanon of the credennal. This means that the security is sound. It has only these System privileges: Create Session, Create Credential, Create Job, Create External Job

35 Serng up a client of my code We then need object privileges Execute on <the code> Select, Insert, Update on <the communication table> Execute on <the o/s credential for joe_no_privleges> Read on directory <used to read the spool file> There s no risk in lerng the client run start SQL*Plus or RMAN as the joe_no_privleges, nor in lerng him read spool files. In a serious usage of this, each client would have its own spool file directory

36 Look at the real code a Live demo (if Nme allows)

37 Agenda The problem The historical approach The new approach, using DBMS_Scheduler Caveat: not quite ready for prime Nme in a CDB Conclusion

38 Conclusion When the embarrassing oversight is corrected, so that spawned SQL*Plus and RMAN scripts will start in the PDB that submiked the job, you ll have a far, far beker alternanve for managing and running this kind of script that is offered by the present pracnce of o/s files, o/s authenncanon, and cron jobs Meanwhile, you have a perfectly fine way to enjoy the intended benefits, for just SQL*Plus scripts The workaround for rman, to use a credennal for sys, implies that the credennal should be owned by Sys too

39