The sysdg privilege – how, when, and why should you use it?

It is recommended that you use the sysdg administrative privilege instead of sysdba administrative privilege to perform operations related to data guard tasks.

Getting ready

For this recipe, you'll need:

• An existing database user (for example, mike) and a password file in the 12c format if you want to complete it using a password-authenticated user
• An existing OS user (for example, kelly), who belongs to the dgdba OS group in order to connect to the database using OS authentication

How to do it...

Instructions are split into sections for database authentication and OS authentication.

Database authentication

The instructions for database authentication are as follows:

1. Connect to the database as sysdba (or another user who can grant the sysdg privilege):

   sqlplus / as sysdba
   

2. Grant SYSDG privilege to user mike:

   SQL> grant sysdg to mike; 
   

3. Exit SQL*Plus, connect mike using the dgmgrl command-line interface:

   SQL> exit
   $ dgmgrl
   DGMRRL> connect mike/test_1
   

OS authentication

The instructions for OS authentication are as follows:

1. Verify that the OS user (for example, kelly) is a member of the dgdba OS group:

   $ id kelly
   

2. Connect using the dgmgrl utility and OS authentication:

   $ dgmgrl
   
   DGMGRL> connect /
   

How it works...

When you connect to the database as sysdg, you are connected as a predefined user, sysdg. Using the sysdg privilege, you can connect to the database even when it is not open.

After completing step 2 successfully in the Database authentication section, user mike, as expected, can grant/revoke sysdg privilege to/from another existing user. If you want to try it out, type the statements given here.

After you connect to the database using the sysdg administrative privilege, you can perform the following operations:

Operations
STARTUP, SHUTDOWN	CREATE SESSION
ALTER SESSION	SELECT ANY DICTIONARY
ALTER DATABASE	FLASHBACK DATABASE
ALTER SYSTEM	EXECUTE SYS.DBMS_DRS
CREATE/DROP RESTORE POINT (including GUARANTEED restore points)	SELECT X$ tables, V$ and GV$ views
DELETE APPQOSSYS.WLM_CLASSIFIER_PLAN	SELECT APPQOSSYS.WLM_CLASSIFIER_PLAN

Tip

It is important for you to remember that:

When using the sysdg administrative privilege, you can't view application data.

There's more...

You can't drop user sysdg. When you are connected to the database as sysdg, you are connected as sysdg user to the SYS schema:

SQL> connect / as sysdg
Connected.

SQL> show user
USER is "SYSDG"

SQL> select sys_context( 'userenv', 'current_schema' ) from dual;
SYS_CONTEXT('USERENV','CURRENT_SCHEMA')
------------------------------------------------------------------
SYS

See also

• Creating password-authenticated users
• Creating and using OS-authenticated users