Have you ever wondered if a database could have a different behavior after a restart? Maybe a parameter was changed and not taken into account, but you have no idea which one?
You can have a look in the “alert log” to find out if someone has recently changed a parameter :
1 2 |
# grep -i "alter system" /u01/oracle/diag/rdbms/FLORA600/FLORA600/trace/alert_FLORA600.log ALTER SYSTEM SET sga_max_size=10G SCOPE=SPFILE; |
But what if the “alert log” recently rotated, and the modification does not appear in the current file?
You can also try to use strings
command on the spfile, if it resides on a regular file system, for example. strings
will display the content of the file in a human-readable way. First, you need to locate the spfile :
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Connected to: Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.8.0.0.0 SQL> show parameter spfile NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ spfile string /u01/app/oracle/product/db_19_8_0_SE2/dbs/spfileFLORA600.ora SQL> exit Disconnected from Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.8.0.0.0 |
Then display its content :
1 2 3 4 5 6 7 |
# strings /u01/app/oracle/product/db_19_8_0_SE2/dbs/spfileFLORA600.ora [...] *.audit_trail='db','extended' *.pga_aggregate_target=1g *.processes=500 *.sga_max_size=10737418240 [...] |
I would not recommend this method because it can be confusing. By using strings
, you will likely have a weird display of the content, with newlines appearing in the middle of some parameters definition. If you want to understand why, then you should read Frits Hoogland’s blog post.
With this method, you can quickly have an idea of what is defined in the spfile. But still, you will have to guess what changed compared to the current state of the parameters.
However, there are 2 very useful dynamic performance views to help you with that : v$spparameter
and v$parameter
.
v$parameter
V$PARAMETER
displays information about the initialization parameters that are currently in effect for the session.
v$spparameter
V$SPPARAMETER
displays information about the contents of the server parameter file.
So even if the spfile contains a specific parameter, it is not necessarily in effect in the current session. It seems now easier to answer the question of this blog post. Let’s join those 2 views and find the parameters with a different value.
1 2 3 4 5 6 7 8 9 10 |
SQL> select vsp.name, vsp.value from v$spparameter vsp, v$parameter vp where vsp.name=vp.name and vsp.value != vp.value ; NAME VALUE ------------------------------ ------------------------------ [...] sga_max_size 10737418240 [...] |
With this example, we understand that parameter sga_max_size
will have a different value once the database is restarted :
1 2 3 4 5 6 7 8 9 10 11 12 |
SQL> show parameter sga_max_size NAME TYPE VALUE ------------------------------------ ----------- -------------- sga_max_size big integer 8G SQL> select value from v$spparameter where name='sga_max_size' ; VALUE --------------------------------------------------------------- 10737418240 |
In view v$parameter
, column ISDEFAULT
is worth noticing because it “Indicates whether the parameter is set to the default value (TRUE
) or the parameter value was specified in the parameter file (FALSE
).” You can have a better understanding of which parameters were modified.
To finish, it is very useful to add a comment whenever you modify a parameter, to track modifications and remember their purpose :
1 2 3 |
SQL> alter system set processes=600 comment='Increase according to ticket no 12032021' scope=spfile; System altered. |
And of course, your comment will appear in the “alert log” as well :
1 2 |
# grep 12032021 alert_FLORA600.log ALTER SYSTEM SET processes=600 COMMENT='Increase according to ticket no 12032021' SCOPE=SPFILE; |
Now, you should be in a better position to foresee any different behavior, due to parameter modification, after an instance restart.