Search This Blog

Wednesday, June 2, 2021

User Management

To check existing users in the system:

column username format a20;
select username, created from all_users order by 2;

select username, account_status, lock_date, expiry_date, 
default_tablespace, temporary_tablespace, created, profile
from dba_users
order by created;


To create a user:

create user u1 identified by u1
default tablespace users
temporary tablespace temp
quota unlimited on users
quota 5m on tbs
password expire
account lock;

 

Assigning the quota to the user on another tablespace:

alter user u1 quota 10m on tbs;

 

To unlock the account:

alter user u1 account unlock;

 

To unlock the account and change the password at the same time:

alter user scott identified by tiger account unlock;

 

To force user to change the password:

alter user u1 password expire;

 

To create the user and grant roles at the same time

grant connect, resource to u1 identified by u1;

 

Granting privileges to users seperately

grant create session, create table, create sequence to u1;

conn u1/u1;

select * from session_privs;

select * from role_sys_privs order by role, privilege;

select * from role_sys_privs order by  1;


Creating and assigning the custom roles

create role role1;

grant create session, create table, create sequence to role1;

grant role1 to u1;

select role, privilege from role_sys_privs where role = 'ROLE1';

select * from dba_role_privs where granted_role = 'ROLE1';

 

Assigning object privileges on a table to other users

connect scott/tiger

grant select, insert, update on emp to u1;

conn u1/u1;

show user;

select * from scott.emp;

 

connect / as sysdba

show user;

column grantee format a10
column owner format a10
column grantor format a10
column table_name format a15
column privilege format a15

select grantee, owner, grantor, table_name, privilege
from dba_tab_privs
where owner = 'SCOTT';

  

Checking the privileges for the user

connect / as sysdba

select role, privilege from role_sys_privs where role = 'ROLE1';

select grantee, privilege from dba_sys_privs where grantee = 'U1';

 

Revoking the privileges from user

conn / as sysdba

revoke select, insert, update on scott.emp from u1;

To confirm the revoke:

select grantee, owner, grantor, table_name, privilege
from dba_tab_privs
where owner = 'SCOTT';

 

Some of the key needed roles (predefined)

connect
resource
dba
exp_full_database
imp_full_database


To use data pump we need below roles:

DATAPUMP_EXP_FULL_DATABASE
DATAPUMP_IMP_FULL_DATABASE

 

Dropping the user Account

If the user schema contains no db objects:

drop user u1;

If the user schema contains db objects:

drop user u1 cascade;

 

Important views related to users and roles

dba_users
select username, account_status, default_tablespace, temporary_tablespace, created
from dba_users;

user_users
select username, account_status, lock_date, expiry_date, created, default_tablespace, temporary_tablespace
from user_users;


all_users
select * from all_users order by 3;


dba_ts_quotas
select username, tablespace_name, bytes, max_bytes, blocks, max_blocks
from dba_ts_quotas;

user_ts_quotas
select tablespace_name, bytes, blocks from user_ts_quotas;
select * from user_ts_quotas;


role_sys_privs
select role, privilege, admin_option from role_sys_privs;


dba_role_privs
select grantee, granted_role, admin_option, default_role from dba_role_privs;

dba_sys_privs
select grantee, privilege, admin_option from dba_sys_privs;

dba_tab_privs
select grantee, owner, table_name, grantor, privilege from dba_tab_privs;
select grantee, owner, table_name, grantor, privilege from dba_tab_privs
where owner='SCOTT';


role_tab_privs
select role, owner, table_name, column_name, privilege from role_tab_privs;

dba_roles
select role, password_required, authentication_type from dba_roles;

role_sys_privs
select role, privilege, admin_option from role_sys_privs;

  

Session Management

Monitoring

desc v$session;

select count(*) from v$session where username is not null;

select username, sid, serial#
from v$session where username is not null;

 

To get session details

column username format a15
alter session set nls_date_format='DD-MM-YYYY HH24:MI:SS';

select username, sid, serial#, status, logon_time
from v$session
where username is not null;


Userwise Sessions

select username, count(*) from v$session
group by username
order by username;


To see the processes by OS username:

select username, pid, pname from v$process;


Joining v$process and v$session

select a.sid, a.serial#, a.username, b.pid, b.spid
from v$session a, v$process b
where a.paddr = b.addr
and a.username = 'SYS';

select username, to_char(logon_time, 'hh24:mi:ss dd-mm-yyyy'),
sid, serial#
from v$session
where sid = 183;


Killing Session at database level

alter system kill session 'SID, SERIAL#';

alter system kill session '23,78';


Killing session from OS level

ps -ef | grep pmon

kill -9 3657

 

 

Creating Password file for instance

$orapwd file=orapw(sid) password=(pwd) force=y ignorecase=y entries=(total users pwd to be stored)

$orapwd file=orapwdb1 password=manager force=y ignorecase=y entries=5

 

Assigning sysdba and sysoper privileges to user

grant sysdba to u1;

grant sysoper to u1;

sqlplus u1/u1 as sysdba;

show user;

SYS

sqlplus u1/u1 as sysoper

show user;

PUBLIC

 

select * from v$pwfile_users;

 

Creating Profile

create profile prof1 limit
     failed_login_attempts 3      (no of attempts)
     password_lock_time 1         (no of days) (1/24 for 1 hour)
     password_life_time 7         (no of days)
     sessions_per_user 5          (no of total sessions)
     idle_time 1                  (in minutes)
     connect_time 600;            (10 hours, in minutes)

 

create profile prof1 limit
     failed_login_attempts 3
     password_lock_time 1
     password_life_time 7
     sessions_per_user 5
     idle_time 15
     connect_time 600;


Assigning Profile

create user u2 identified by u2 profile prof1;

alter user u1 profile prof1;

desc dba_profiles;

select * from dba_profiles where profile='PROF1' order by resource_name;

select resource_name, limit from dba_profiles where profile = 'PROF1';

select username, profile from dba_users where profile = 'PROF1';

alter profile prof1 limit password_lock_time 2;

select * from dba_profiles where profile = 'PROF1';

 

To enforce kernel / resource parameters, the following parameter must be set

alter system set resource_limit = true scope = both;

 

Applying password restriction in profile

@$ORACLE_HOME/rdbms/admin/utlpwdmg.sql;

alter profile default limit password_verify_function null;

alter profile prof1 limit password_verify_function verify_function;


To remove the above function:

alter profile prof1 limit password_verify_function null;

 

By default password is case sensitive, to disable it set the following parameter to false

sec_case_sensitive_logon = false

alter system set sec_case_sensitive_logon = true scope = both;


Upgrading

 Soon

Friday, May 28, 2021

Online Redolog Files Management

To check the current Online Redo Log file information:

set linesize 200 pagesize 30
select group#,thread#,sequence#,bytes/1024/1024/1024 size_gb,
members,archived,status
from v$log
order by group#;

set linesize 200 pagesize 30
col member for a50
select group#,type,member from v$logfile order by group#;

col member for a50
select a.group#, thread#,sequence#, bytes/1024/1024/1024 size_gb, members, 
a.status, type, member
from v$log a,v$logfile b
where a.group# = b.group#
order by a.group#;

Adding redo log group to the database

alter database add logfile
group 4 '/u01/prod/redo04a.log'
size 50m;

Droping redo log group from database

col member for a50
select group#, member from v$logfile order by group#;

alter database drop logfile group 4;

Adding redo log member to an existing group

alter database
add logfile member '/u01/prod/redo04b.log'
to group 4;

Drop  redo log member from the database

column member format a50
select group#, member from v$logfile order by group#;

alter database drop logfile member '/u01/prod/redo04b.log';

select group#, member from v$logfile order by group#;


Resizing redo log groups (create new ones and delete old ones after few log switches)

select group#, status, bytes/1024/1024/1024 size_gb from v$log order by group#;

alter database add logfile group 4 '/u01/prod/redo04.log' size 100m;

alter database add logfile group 5 '/u01/prod/redo05.log' size 100m;

alter database add logfile group 6 '/u01/prod/redo06.log' size 100m;


alter system switch logfile;

/

/

/

select group#, members, status from v$log order by group#;

now drop the old ones

alter database drop logfile group 1;

alter database drop logfile group 2;

alter database drop logfile group 3;

select group#, members, status, bytes from v$log order by group#;

now all will be of 100m size


https://docs.oracle.com/cd/A57673_01/DOC/server/doc/SAD73/ch5.htm#:~:text=To%20drop%20specific%20inactive%20online,DROP%20LOGFILE%20MEMBER%20'log3c'%3B

Oracle Performance Tuning

Statistics

The Oracle Optimizer examines all of the possible plans for a SQL statement and picks the one with the lowest cost, where cost represents the estimated resource usage for a given plan. In order for the optimizer to accurately determine the cost for an execution plan it must have information about all of the objects (table and indexes) accessed in the SQL statement as well as information about the system on which the SQL statement will be run.

This necessary information is commonly referred to as optimizer statistics. Understanding and managing optimizer statistics is key to optimal SQL execution. Knowing when and how to gather statistics in a timely manner is critical to maintaining acceptable performance.

» How to gather statistics 
» When to gather statistics 
» Improving the quality of statistics 
» Gathering statistics more quickly 
» When not to gather statistics 
» Gathering other types of statistics

select table_name,num_rows,last_analyzed from dba_tables where owner='SCOTT';

Automatic Statistics Gathering

The Oracle database collects statistics for database objects that are missing statistics or have “stale” (out of date) statistics. This is done by an automatic task that executes during a predefined maintenance window. Oracle internally prioritizes the database objects that require statistics, so that those objects, which most need updated statistics, are processed first. 

The automatic statistics-gathering job uses the DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC procedure, which uses the same default parameter values as the other DBMS_STATS.GATHER_*_STATS procedures. The defaults are sufficient in most cases. However, it is occasionally necessary to change the default value of one of the statistics gathering parameters, which can be accomplished by using the DBMS_STATS.SET_*_PREF procedures. Parameter values should be changed at the smallest scope possible, ideally on a per-object basis. For example, if you want to change the staleness threshold for a specific table, so its statistics are considered stale when only 5% of the rows in the table have changed rather than the default 10%, you can change the STALE_PERCENT table preference for that one table using the DBMS_STATS.SET_TABLE_PREFS procedure. By changing the default value at the smallest scope you limit the amount of non-default parameter values that need to be manually managed. For example, here’s how you can change STALE_PRECENT to 5% on the SALES table:

exec dbms_stats.set_table_prefs(user,'SALES','STALE_PERCENT','5');

To check what preferences have been set, you can use the DBMS_STATS.GET_PREFS function. It takes three arguments; the name of the parameter, the schema name, and the table name:

SQL> select dbms_stats.get_prefs('STALE_PERCENT','SCOTT','EMP') stale_percent from dual;

STALE_PERCENT
--------------------
10


Setting DBMS_STATS Preferences

It is possible to set DBMS_STATS preferences to target specific objects and schemas to modify the behavior of auto statistics gathering where necessary. You can specify a particular non-default parameter value for an individual DBMS_STATS.GATHER_*_STATS command, but the recommended approach is to override the defaults where necessary using “targeted” DBMS_STATS.SET_*_PREFS procedures.

A parameter override can be specified at a table, schema, database, or global level using one of the following procedures (noting that AUTOSTATS_TARGET and CONCURRENT can only be modified at the global level): 

SET_TABLE_PREFS 
SET_SCHEMA_PREFS 
SET_DATABASE_PREFS 
SET_GLOBAL_PREFS 

Traditionally, the most commonly overridden preferences have been ESTIMATE_PERCENT (to control the percentage of rows sampled) and METHOD_OPT (to control histogram creation), but estimate percent is now better left at its default value for reasons.

The SET_TABLE_PREFS procedure allows you to change the default values of the parameters used by the DBMS_STATS.GATHER_*_STATS procedures for the specified table only.

The SET_SCHEMA_PREFS procedure allows you to change the default values of the parameters used by the DBMS_STATS.GATHER_*_STATS procedures for all of the existing tables in the specified schema. This procedure actually calls the SET_TABLE_PREFS procedure for each of the tables in the specified schema. Since it uses SET_TABLE_PREFS, calling this procedure will not affect any new objects created after it has been run. New objects will pick up the GLOBAL preference values for all parameters.

The SET_DATABASE_PREFS procedure allows you to change the default values of the parameters used by the DBMS_STATS.GATHER_*_STATS procedures for all of the user-defined schemas in the database. This procedure actually calls the SET_TABLE_PREFS procedure for each table in each user-defined schema. Since it uses SET_TABLE_PREFS, this procedure will not affect any new objects created after it has been run. New objects will pick up the GLOBAL preference values for all parameters. It is also possible to include the Oracle owned schemas (sys, system, etc) by setting the ADD_SYS parameter to TRUE.

The SET_GLOBAL_PREFS procedure allows you to change the default values of the parameters used by the DBMS_STATS.GATHER_*_STATS procedures for any object in the database that does not have an existing table preference. All parameters default to the global setting unless there is a table preference set, or the parameter is explicitly set in the GATHER_*_STATS command. Changes made by this procedure will affect any new objects created after it has been run. New objects will pick up the GLOBAL_PREFS values for all parameters.

The DBMS_STATS.GATHER_*_STATS procedures and the automated statistics gathering task obeys the following hierarchy for parameter values; parameter values explicitly set in the command overrule everything else. If the parameter has not been set in the command, we check for a table level preference. If there is no table preference set, we use the GLOBAL preference.

 

Oracle Database 12 Release 2 includes a new DBMS_STATS preference called PREFERENCE_OVERRIDES_PARAMETER. When this preference is set to TRUE, it allows preference settings to override DBMS_STATS parameter values. For example, if the global preference ESTIMATE_PERCENT is set to DBMS_STATS.AUTO_SAMPLE_SIZE, it means that this best-practice setting will be used even if existing manual statistics gathering procedures use a different parameter setting (for example, a fixed percentage sample size such as 10%).










Ahmad Barakah
===========

9.
Performance Issue Attributes
  • Scope (entire db or part of it, specific functionality, session, user, batch, action etc.)
  • Very slow or hang
  • Permanent or intermittent
  • Is it reproducible
  • Specific Errors :
    ORA-00257: archiver error, connect internal only, until freed
    ORA-04031: unable to allocate n bytes of shared memory (due to small shared pool)

10. Performance Tuning Methodology

    1. Set a mesurable target (ask questions to the user)
    2. Discover the symptoms (generate comparison awr reports) (awr, addm, ash, v$, os level)
    3. Determine possible causes
    4. Develop a trial solution (follow addm recom, create index etc)
    5. Test the solution - Target Hit - End - No then go to step 3 and repeat


11. A Typical System Workload Example

    Number of users         : 100
    Transaction rate          : 1 trx per 5 min per user
    Business hours            : 8 hours in 5 working days (5x8)
    Calculated rate            : 20 trx per min, 9600 transactions daily 
    Peak rate                      : 120 trx per minute


12. 
    Server Performance Measurement Aspects
    1. CPU
    2. Memory
    3. Storage
    4. Network
    All above are physical specifications


14. Performance Tuning Tools
  • v$ views and data dictionary views
  • Automatic Workload Repository (AWR)
  • Statspack reports
  • Automatic Database Diagnostic Monitor (ADDM)
  • Performance tuning advisors
  • alertlog file
  • Trace files
  • Enterprise Manager Cloud Control and EM Database Express
Types of Performance Tuning Statistics
  • Cumulative statistics: mostly have no meaning without the time factor 
    • Time model
    • Wait events
  • Metrics: statistic rates
  • Sampled statistics
    • ADDM, AWR, Active Session History (ASH)
Setting Statistics Level
  • STATISTICS_LEVEL controls the level of collecting database and operating system statistics. 
    • BASIC: Most important performance statistics are not collected
    • TYPICAL: All major statistics are collected
    • ALL: Timed operating system statistics and execution plan statistics are added
  • Can be altered at the system and session levels
  • To know which parameter is affected by setting this parameter, query the view V$STATISTICS_LEVEL

Section: 6 Using Time Model 

15. 
DB Time
        Idle waiting
        Perform processing (DB CPU) once receive request from the clients by using cpu, ram, disk
        Waiting for a resource (DB waits)

DB Time = performing processing + Waiting for a resource
DB Time = DB CPU + total DB waits

Time Mode = DB Time = SQL + Connect + Java + PLSQL + RMAN + Parse

16. About Time Model 
  • Is a set of statistics that give an overview on which operation types the DB time is spent inside the Oracle database
  • Available in: V$SYS_TIME_MODEL and V$SESS_TIME_MODEL
  • DB time represents the time the database spent on executing the user calls (DB CPU and DB waits)
  • Statistics are accumulated since instance startup
  • Benefits:
    • Single indicator on the entire database workload and performance
    • Study the impact of a change on the entire database performance
    • May trigger investigating into performance issues

17. Time Model Hierarchy
DB time
    DB CPU
    connection management call elapsed time
    sequence load elapsed time
    sql execute elapsed time
    parse time elapsed
        hard parse elapsed time
            hard parse (sharing criteria) elapsed time
                hard parse (bind mismatch) elapsed time
        failed parse elapsed time
            failed parse (out of shared memory) elapsed time
    PL/SQL execution elapsed time
    inbound PL/SQL rpc elapsed time
    PL/SQL compilation elapsed time
    repeated bind elapsed time

background elapsed time
    background cpu time
        RMAN cpu time (backup/restore)


Database Time Model Query Example

select stat_name, to_char(value/10000000, '999,999') time_s
from v$sys_time_model
where value <> 0 and stat_name not in ('background elapsed time', 'background cpu time')
order by value desc;

Sessions Time Model Query Example

select s.sid, s.username, t.stat_name, 
round(t.value/1000000,2) "Time (SEC)"
from v$sess_time_model t, v$session s
where t.sid = s.sid and t.stat_name in ('DB time', 'DB CPU')
and s.username is not null
order by t.value desc;

Using Time Model to Measure System Scalability

select to_char(dbtime.value/1000000,'999,999') dbtime,
to_char(dbcpu.value/1000000,'999,999') dbcpu,
to_char((dbtime.value-dbcpu.value)/1000000,'999,999') wait_time,
to_char((dbtime.value-dbcpu.value)/dbtime.value*100,'99.99') || '%' wait_pct,
(select count(*) from v$session where username is not null) users_cnt
 from v$sys_time_model dbtime, v$sys_time_model dbcpu
 where dbtime.stat_name = 'DB time' and dbcpu.stat_name = 'DB CPU';


Historical System Time Model Statistics
  • Can be retrieved from DBA_HIST_SYS_TIME_MODEL
  • Has an advantage over reading from the V$ views.

18. Using Time Model

Lot of good commands will be created in the scripts folder

Note: We got scripts folder and .pdf file to help this lesson


19. Using Time Model


Section 7: Using Instance Activity Statistics

20. Using Instance Activity Statistics 1
About Instance Activity and Wait Events
  • Instance activity statistics:
    • Quantitative measures on the instance activities
    • Their figures (at the system level) can be obtained from V$SYSSTAT
    • Each statistic can belong to one or more from 8 statistic classes
    • Their names are described in V$STATNAME

Instance Activity Statistic Views
  • System:
    • V$SYSSTAT
  • Services:
    • V$SERVICE_STATS
  • Sessions:
    • V$SESSTAT
    • V$MYSTAT
    • Note: Usually linked with V$STATNAME
  • Segment:
    • V$SEGMENT_STATISTICS

21. Using Instance Activity Statistics 2
System Statistic Classes
Class Number    Class Name
-----------------------------------
1        User
2        Redo
4        Enqueue
8        Cache
16      OS
32      Real Application Cluster
64      SQL
128    Debug

  • Can be retrieved from the CLASS column in V$SYSSTAT and V$STATNAME views (V$SESSTAT view does not have it)

Instance Activity Query Example

select name, class, value from v$sysstat;

Obtaining Activity Statistics of Specific Statements

---(1) obtain the current statistics value from v$mystat:
select s.value into :value1
from v$mystat s, v$statname n
where s.statistics# = n.statistic#
and name = 'CPU used by this session';

--(2) execute the statements:

--(3) obtain the current statistics value from v$mystat:
select s.value into :value2
from v$mystat s, v$statname n
where s.statistic# = n.statistic#
and name = 'CPU used by this session';

--(4) substract values obtained in (3) from (1)
:delta := :value2 - :value1



Section 8: Wait Events
=================

Patching

Types of patches:

1. Interim patch (single patch)
2. Patchset patch (collection of patches)

We install interim patching using opatch utility and patchset we install using Oracle Universal Installer (OUI).


Applying Interim Patch

Location of opatch utility = $ORACLE_HOME/OPatch

These patches were released by oracle on a quarterly basis in January, April, July and October.

We should not install these patches until unless there is a need for it. We can search for this quarterly patch in google and download it from oracle website.

Once you unzip the downloaded file it will create a folder with patch number.

Inside the folder apart from patch files there is readme.txt.  Go through this file.  This will tell us which bug this patch is going to fix.

Stop all the services like database, listener and dbconsole etc.

Go to $ORACLE_HOME/OPatch folder

To apply the patch:

$opatch apply <patch id>

To see the information which problem the patch is going to fix:

$opatch query

To get the installed patches information:

$opatch lsinventory

(This will read the file $ORACLE_HOME/ContentsXML/comps.xml)

To see the version of opatch utility:

$opatch version

To rollback the patch:

$opatch rollback -id <patch id>

$opatch rollback -id 1234567

To restore a failed patch:

$cd $ORACLE_HOME/.patch_storage/<patchid-timestamp>

$./restore.sh

Wednesday, May 26, 2021

ADRCI

We must start ADRCI command inside ADR base.

cd /u01/app/oracle  (is my adr base)

adrci (press enter)

adrci> help

The main use of adrci command line utility is to view alert log file and trace files.

show alert

Choose the alert log from the following homes to view:

1: diag/tnslsnr/m1/listener
2: diag/asm/+asm/+ASM
3: diag/rdbms/prod/prod
Q: to quit

Here choose 3 to read alert log file.

3 (press enter)

This will show the entire alert log file.  To quit this alert log file:
:quit

We will come back to main menu. To quit from here press Q.

To see the last 20 lines from the alert log file:

show alert -tail 20
This will throw below error as we got here multiple adr homes, like asm and rdbms etc.
DIA-48449: Tail alert can only apply to single ADR home

to clear the screen we can use the below command:
host "clear"

We need to set a single home to use tail command. To set rdbms home:
set home diag/rdbms/prod/prod

now we use the command to see bottom 20 lines 
show alert -tail 20

If we only want to see ORA- error messages:
show alert -p "message_text like '%ORA-%'"

If we want to see only the incidents:
show alert -p "message_text like '%incident%'"

To see the list of trace files:
show tracefile

To see a particular trace file from the above list:
show trace /u01/app/oracle/diag/rdbms/prod/prod/trace/prod_vkrm_5427.trc

Tuesday, May 25, 2021

Password File

Default directory for Oracle Password File:
$ORACLE_HOME/dbs/orapw$ORACLE_SID on Unix
%ORACLE_HOME\database\PWD%ORACLE_SID%.ora on Windows.

To use password file to login to server from a remote machine we need to set this parameter:

show parameter remote_login_passwordfile;

The value for above parameter should be:
EXCLUSIVE for a single instance database.
SHARED for a RAC database.
NONE means no password file.  We can't use password file to login to server as admin from a remote machine.  Even the file exists oracle will ignore it.

Listener must be running in the source machine.  Tns entry must be working from remote machine to the server.

orapwd is the exe we use to create password file. Which lies inside bin folder.

To see all available options:
orapwd help=y

When we run below command oracle will ask password for SYS user.  After giving password it will add SYS user to password file.  We are executing orapwd command inside dbs folder.  If we are running this command from outside we must provide file=path.

orapwd file=orapwprod entries=5 force=y ignorecase=y

We can give password for SYS user inside the above command:

orapwd file=orapwprod password=manager entries=5 force=y ignorecase=y


Generally we login to oracle DB with OS authentication like below:

sqlplus / as sysdba

Here '/' means OS credentials.

To login from a remote machine as sysdba we use the below method:

sqlplus sys/manager@toprod as sysdba


To confirm password file is being used or not:

At Source DB:
shutdown immediate;
rename the password file to orapwprod.bak
startup mount;

By keeping the source db in mount mode, now try this from remote machine:
sqlplus sys/manager@toprod as sysdba
this will throw an error : insufficient privileges

At Source DB:
shutdown immediate;
rename the password file to the original name as orapwprod
startup mount;

From Remote machine:
sqlplus sys/manager@toprod as sysdba
We are able to connect in mount mode.

to confirm
select open_mode, name, host_name from v$database,v$instance;
MOUNTED, PROD, m1.dba.com


Users are added to the password file when they are granted the SYSDBA, SYSOPER, SYSASM, SYSKM, SYSDG or SYSBACKUP privilege.  By default, SYS is the only user that has SYSDBA and SYSOPER privileges.

To check the number of users with SYSDBA and SYSOPER privileges:
select * from v$pwfile_users;


To create a new user 'u1' and grant sysdba privilege, and confirm its addition to the password file:

creat user u1 identified by u1;
grant sysdba to u1;

select * from v$pwfile_users;
USERNAME        SYSDB SYSOP SYSAS
------------------------------ ----- ----- -----
SYS                TRUE  TRUE  FALSE
U1                TRUE  FALSE FALSE

We can grant both SYSDBA and SYSOPER roles to a user:
create user u2 identified by u2;
grant sysdba, sysoper to u2;

select * from v$pwfile_users;
USERNAME        SYSDB SYSOP SYSAS
------------------------------ ----- ----- -----
SYS                TRUE  TRUE  FALSE
U1                TRUE  FALSE FALSE
U2                TRUE  TRUE  FALSE

If we delete the orapwprod file all the above 3 records will be gone.  Password file will become empty. We can't login as sysdba from remote machine. But we can still login as a normal user.

In the password creation command if entries=2 then, even though we granted sysdba privilege to 'n' number of users only 2 can login as sysdba at a time.

As the password file is a binary file, to see the contents inside it at OS level:
strings orapwprod

As we added user 'U1' to the password file, we can login to db from a remote machine using U1 credentials as:

sqlplus u1/u1@toprod as sysdba

Now we can startup or shutdown the db using U1 credentials.

Even through we logged in using U1 credentials still it will show as 'SYS' user with below commands:

select user from dual;
show user;

Saturday, May 22, 2021

Alert Log File

Check Alert Log File Location in Oracle

If the db is up and running:

show parameter dump;
(here look for the parameter background_dump_dest)

select value from v$parameter where name = 'background_dump_dest';
(here look for the path)

Go to the file location and list the last 100 lines:

tail -100f alert_prod.log


If DB is Down

find / -name alert_prod.log 2>/dev/null

Saturday, May 15, 2021

Oracle Database Managed Files Setup (OMF)

This will eliminate the need for a dba to directly manage the operating system files in a database.

After this configured we can just create a database object without specifying the file path.

OMF will support below objects:
Tablespaces
redo log files
control files
archived logs
block change tracking files
flashback logs
RMAN backups

To enable OMF we must configure below parameters:
DB_CREATE_FILE_DEST (datafiles, temp files)
DB_CREATE_ONLINE_LOG_DEST_n (redo log and control files) DB_RECOVERY_FILE_DEST (fra)

To setup these parameters:

alter system set db_create_file_dest='/u01/prod';

alter system set db_create_online_log_dest_1='/u01/prod';


To set FRA:

alter system set db_recovery_file_dest_size = 10G;

alter system set db_recovery_file_dest = '/u01/fra';

Once the above parameter setup we create a tablespace with this command:

create tablespace test;

(here size of the datafile and location and other parameters oracle takes automatically)
Default size of the datafile will be 100MB.
It will be Locally Managed Tablespace.