Nowadays, a DBA has to know how to administer a database on-premise but also on Cloud. Cloud is not the future, it's the present. Several databases are being moved from on-premise to Cloud. Since we are in the transition phase, a DBA has to know how to shutdown, start, create tablespaces, change database parameters, and several more tasks on Amazon RDS, Oracle Public Cloud, Microsoft Azure, others providers and of course on-premise. Every Cloud provider have several similar things, but also they have several different ways to performa a task. In this article I will cover how to change the values for database parameters in Amazon RDS. If you are an experienced on-premise Oracle DBA you would wonder "To change database parameters" is the easiest thing, and it is, indeed, but it is different on Amazon RDS and you will see why.
I have broken up the article in the following sections:
- The on-premise approach
- The research
- How to change DB parameters in Amazon RDS using AWS Management Console
- How to change DB parameters in Amazon RDS using CLI
- Conclusion
For this article I have used the following environment:
Database Name: Oracle
Database Type: Amazon RDS - Single Instance
Database version: 12.1.0.2
The on-premise approach
An experienced on-premise DBA would want to execute an "ALTER SYSTEM SET", at the end, the user that provides Amazon RDS has the role "DBA", and the privilege "ALTER SYSTEM" is included in that role. Let's follow that approach and let's see what happens:
SQL> alter system set statistics_level='BASIC' scope=spfile;;
alter system set statistics_level='BASIC'
*
ERROR at line 1:
ORA-01031: insufficient privileges
So, here is the first problem we have. If we were using an on-premise database with an user that has "DBA" role, the same sentence works:
SQL> alter system set statistics_level='BASIC' scope=spfile;
System altered.
The only difference is that the first database was on Amazon RDS and the second was on-premise. So in this "difference" there should be the "reason" of that "insufficient privileges" error. Now let's move on to the research part.
The research
The first question we have to clarify is why one user with "DBA" role doesn't have privilege to execute "ALTER SYSTEM". The reason is that in Amazon RDS, the role "DBA" has two privileges less than an on-premise database:
In Amazon RDS:
SQL> select count(*) from dba_sys_privs where grantee='DBA' and privilege like 'ALTER%';
COUNT(*)
----------
32
On-premise database (same version, 12.1.0.2):
SQL> select count(*) from dba_sys_privs where grantee='DBA' and privilege like 'ALTER%';
COUNT(*)
----------
34
I found that the two privileges that were removed are:
- ALTER DATABASE
- ALTER SYSTEM
So that's the reason why we can not execute "ALTER SYSTEM SET" in our Oracle Amazon RDS.
Now you would think: Why not use SYS? and here is the second thing that an Oracle database on Amazon RDS has different compared with on-premise. An Oracle Database on Amazon RDS doesn't allow to use SYS, SYSTEM users, as per the Amazon documentation:
"The SYS user, SYSTEM user, and other administrative accounts are locked and cannot be used."
I also recommend to read the following notes:
- Oracle Database Support for Amazon AWS EC2 (Doc ID 2174134.1)
- Amazon RDS Support for AIA (Doc ID 2003294.1)
Amazon documentation says two things: Locked and it cannot be used.
It is not correct regarding the first property, both SYS and SYSTEM users are not locked:
SQL> select username, account_status from dba_users where username in ('SYS','SYSTEM')
USERNAME ACCOUNT_STATUS
------------- -----------------
SYSTEM OPEN
SYS OPEN
But Amazon Documentation is correct, when it says that they cannot be used, and you will know why [:)]
It tried to change the password of SYS just for fun and the output was this:
SQL> alter user sys identified by Manager1;
alter user sys identified by Manager1
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-20900: ALTER USER SYS not allowed.
ORA-06512: at "RDSADMIN.RDSADMIN", line 208
ORA-06512: at line 2
That was my first meeting with RDSADMIN.RDSADMIN.
When I saw "RDSADMIN.RDSADMIN" I thought: "I can change the password of SYS, but this function RDSADMIN.RDSADMIN is not allowing it". I mean, without this function that sentence should work. Of course this is a customized function created by Amazon RDS, it is not created by default by Oracle Database.
Then I took a look into that function:
SQL> select owner, trigger_name, trigger_type, status, triggering_event, trigger_body from dba_triggers where owner='RDSADMIN' and triggering_event like '%DDL%';
OWNER TRIGGER_NAME TRIGGER_TYPE STATUS TRIGG TRIGGER_BODY
-------- --------------- ------------ -------- ----- ------------
RDSADMIN RDS_DDL_TRIGGER BEFORE EVENT ENABLED DDL BEGIN
rdsadmin.secure_ddl;
END;
RDSADMIN RDS_DDL_TRIGGER2 BEFORE EVENT ENABLED DDL BEGIN
rdsadmin.secure_ddl;
END;
Firstable I don't understand why there are two triggers with the same trigger type, the same triggering even, the same status (enabled) and calling exactly the same procedure (rdsadmin.secure_ddl), it seems like if Amazon RDS developers were playing on production? Who knows!.
Anyways I tried to disable that trigger, at the end my user has "DBA" role, right? :)
SQL> alter trigger RDSADMIN.RDS_DDL_TRIGGER disable;
alter trigger RDSADMIN.RDS_DDL_TRIGGER disable
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-20900: RDS restricted DDL found: ALTER TRIGGER SYS.RDS_DDL_TRIGGER
ORA-06512: at "RDSADMIN.RDSADMIN", line 407
ORA-06512: at line 2
Again our friend RDSADMIN.RDSADMIN....
I did a research on the package "RDSADMIN.RDSADMIN" and after several tests and different inputs, and some cups of coffee, by observation I found the following:
- It is a customized package that is included in any Oracle Database on Amazon RDS that is on charge to verify what it is allowed and what it's not. If you are SYS, SYSTEM or RDSADMIN likely all the validations performed by this package are not applied. But if you are another user, several validations are performed on the sentence that you are trying to execute.
- It doesn't allow you to grant the privileges ALTER SYSTEM, ALTER DATABASE,GRANT ANY PRIVILEGE, DATAPUMP_EXP_FULL_DATABASE,DATAPUMP_IMP_FULL_DATABASE,IMP_FULL_DATABASE,EXP_FULL_DATABASE. If you try to do it, you will get the error "ORA-20997".
- It validates which objects are being touched in the sentence you are executing and if those objects belong to the schemas SYS, SYSTEM and RDSADMIN it cancel your sentence and you will receive the error "ORA-20900". For example, when I tried to disable the trigger.
- It doesn't allow you to alter or to drop the schema RDSADMIN.
- it doesn't allow you to change the password of SYS, SYSTEM and RDSADMIN users.
- it doesn't allow you to revoke any privilege from the RDSADMIN user. (This is the first time that with an user that has DBA role I felt too unprivileged [:(])
- it doesn't allow you to ALTER or DROP the tablespace RDSADMIN (Yes, there is a tablespace called RDSADMIN that is created by default. Also an user profile called RDSADMIN. RDSADMIN is everywhere! [:|] ! )
- It doesn't allow to add datafiles to any tablespace specifying a full path. You must let the OMF to handle that.
- It allows you to create new tablespaces. omg! finally! [:D]
- It allows you to compile packages, procedures, functions, triggers and views. Only to compile.
So when someone asks you why it is not possible to change a db parameter with "ALTER SYSTEM", you will know what to say :)
How to change DB parameters in Amazon RDS using AWS Management Console
In order to Change a DB parameter on Amazon RDS, you must use a "Parameter Group". I like the concept behind this because it is cloud-oriented concept, which is good. A Parameter Group, as the name says, it is a set of parameters identified by a name. The good thing of this is that a "Parameter Group" can be shared with several Oracle Database Instances. Instead to manage several parameters for every single database instance as on-premise, Amazon allows you to create only one single group and to re-use that group across several database instances. That way you will have your databases standardized. You can have a Parameter Group for all your Dev databases, another Parameter Group for all your Test Databases, and so on.
You can set a Parameter Group for your database when you are creating the Oracle RDS:
Or you can create a Parameter Group any time after the database creation. In this case, at the time of the creation Amazon will assign a default Parameter Group usually called "default.oracle-ee-12.1". The problem of this is that the default Parameter Group cannot be modified. You cannot change the value of any parameter inside that default one.
Since a default Parameter Group cannot be modified, we must create another one. To do so, go to AWS Management Console -> Parameter Groups and click on Button "Create Parameter Group" and follow the instructions:
You have to Select a "Parameter Group Family" which is basically for which kind of database you are creating the Parameter Group:
the Parameter Group Family could be one of the following:
Provide the name for the Parameter Group and a Description as well. Click on the button "Create".
When the Parameter Group is created, you can be able to modify the values of the parameters.
For non-default Parameter Group you have to click on AWS Management Console -> Parameter Groups -> [your non-default Parameter Group] and then click on the button "Edit Parameters". There will be a page where you will find all the parameters and you will be able to change the values:
Once you have modified all the required parameters, click on the button "Save Changes". Be aware that every parameter could be either "dynamic" or "static". All the dynamic parameters will be applied immediately regardless the "Apply Immediately" setting. However for the Static parameters you will have to reboot the Oracle RDS Instance.
If you want to know if your change was applied Immediately or it will be applied after a reboot you can check AWS Management Console -> Parameter Groups ->[ your non-default Parameter Group] -> Recent Events (Button)
How to change DB parameters in Amazon RDS using CLI
Amazon provides a terminal tool (CLI). It allows to make changes faster than in Amazon AWS Management Console.
To list the Parameter Groups:
Deibys-MacBook-Pro$ aws rds describe-db-parameter-groups
{
"DBParameterGroups": [
{
"DBParameterGroupArn": "arn:aws:rds:us-west-2:062377963666:pg:default.oracle-ee-12.1",
"DBParameterGroupName": "default.oracle-ee-12.1",
"DBParameterGroupFamily": "oracle-ee-12.1",
"Description": "Default parameter group for oracle-ee-12.1"
}
]
}
To List All the Parameter of a Parameter Group:
Deibys-MacBook-Pro$ aws rds describe-db-parameters --db-parameter-group-name default.oracle-ee-12.1
{
"Parameters": [
{
"ApplyMethod": "pending-reboot",
"Description": "_allow_level_without_connect_by",
"DataType": "boolean",
"AllowedValues": "TRUE,FALSE",
"Source": "engine-default",
"IsModifiable": true,
"ParameterName": "_allow_level_without_connect_by",
"ApplyType": "dynamic"
},
{
"ApplyMethod": "pending-reboot",
"Description": "_always_semi_join",
"DataType": "string",
"AllowedValues": "CHOOSE,OFF,CUBE,NESTED_LOOPS,MERGE,HASH",
"Source": "engine-default",
"IsModifiable": true,
"ParameterName": "_always_semi_join",
"ApplyType": "dynamic"
},
{.......}
]
}
The output can have a different format:
Deibys-MacBook-Pro$ aws rds describe-db-parameters --db-parameter-group-name default.oracle-ee-12.1 --output table
or
Deibys-MacBook-Pro$ aws rds describe-db-parameters --db-parameter-group-name default.oracle-ee-12.1 --output text
To filter one single parameter in a Parameter Group:
Deibys-MacBook-Pro$ aws rds describe-db-parameters --db-parameter-group-name default.oracle-ee-12.1 --output text --query "Parameters[?ParameterName=='statistics_level']"
or
Deibys-MacBook-Pro$ aws rds describe-db-parameters --db-parameter-group-name default.oracle-ee-12.1 --output table --query "Parameters[?ParameterName=='statistics_level']"
And finally, you change a parameter value with the following sentence:
Deibys-MacBook-Pro$ aws rds modify-db-parameter-group --db-parameter-group-name nuvolaparameters --parameters "ParameterName=statistics_level,ParameterValue=basic,ApplyMethod=pending-reboot"
{
"DBParameterGroupName": "nuvolaparameters"
}
Deibys-MacBook-Pro$
Conclusion
To finish the article I would say that to use a Parameter Group is a good approach for on-cloud databases, because they can be shared across several databases and that allows to Standardize. Both Amazon AWS Management Console and CLI allows a fast method to change parameters.
I didn't like RDSADMIN.RDSADMIN package because I am a DBA, I am used to have the control of everything inside the database, but I understand the security perspective of Amazon, also I understand that RDS is that... "Relational Database Service" and that means others have the control, others maintain the database. It doesn't make sense that if it is a "DaaS" I still have to maintain the database, so that's fine. by using a DaaS, I could be focused on others areas like SQL Tuning, Instance Tuning, Reporting for the board of directors, capacity planning, monitoring, etc, etc. So at the end, the package is fine. [H]
I think Amazon should ask if we want to apply the changes on memory, or spfile or both, instead to apply immediately whenever it's possible. +1 for Oracle Public Cloud :)
Always create your own Parameter Group , before to create a database, so that you can use it since the beginning. The problem to use a default Parameter Group is that when you require to change a parameter value you will have to create a new Parameter Group, stop the database and to assign the new Parameter Group, and that means Downtime, mostly when you database is already used by clients.
Follow me:
About the Author: Deiby Gómez is an Oracle ACE Director from Guatemala, he has the certifications Oracle Certified Master 11g and Oracle Certified Master 12c. Deiby Gómez currently works for Nuvola Consulting Group, a Guatemalan company that provides Consulting Services for Oracle Products. He is the winner of “SELECT Journal Editor's Choice Award 2016”. Deiby has been Speaker in Collaborate in Las Vega USA, Oracle Open World in San Francisco USA and in Sao Paolo Brazil.
