Skip navigation.

Yann Neuhaus

Syndicate content
All blog entries from http://www.dbi-services.com/
Updated: 17 hours 22 min ago

How to list all Oracle system schemas

Thu, 2014-06-05 04:51

Do you want to know which users come with the Oracle Database and which are the ones you have created? This is that not easy, especially prior to Oracle 12c. You know SYS and SYSTEM, but there are many others - especially when you have installed all options.

And it is important to know them all, e. g. when you import or apply a password policy, etc.

Let's see the options we have.

 

12c shows Oracle maintained users

Oracle 12c has introduced the ORACLE_MAINTAINED in the DBA_USERS dictionary view.

It is YES for the users created by oracle scripts (create database, calalog.sql, catproc.sql). So it's the right place to check when you are in 12c. 

 

12c Common users

Oracle 12c has another column to distinguish the user commonality. This is for CDB: the oracle dictionary is stored in the root container, and each PDB have links to it. And what is nice is that even when in a non-cdb the column is at 'YES' for Oracle maintained users and at 'NO' for created users. (except if you create C## common users in a cdb).

 

Default passwords

The table sys.default_pwd$ stores the default password hash value so that we can check which users can log with trivial password. Even if it includes all the Oracle maintained users, it has also some well known users which are not provided by database creation at all.

 

Sysaux occupants

Another idea that I took from Martin Bach is to crosscheck check with v$sysaux_occupants. Some Oracle provided users are missing, but the nice thing is that there is a description for the schemas that are listed.

 

Not exported by DataPump

DataPump maintains its own list of users for which the tables are not exported, and you can query sys.ku_noexp_tab for that. The old exp has also its list stored in sys.exu8usr. But both are not exhaustive.

Another exclusion list is the one used by logical standby: system.logstdby$skip which may be used as well to crosscheck (only records with 'action=0' are relevant for schema exclusion).

Let's check all that on a 12c non-cdb database. Here is the query that crosscheck all than information with outer joins:

select created,username,oracle_maintained,common,no_exp,no_expdp,no_sby,default_password,sysaux,occupant_desc
from dba_users 
left outer join 
 (select distinct name username,'Y' no_expdp from sys.ku_noexp_tab where obj_type='SCHEMA') 
 using(username)
left outer join (select distinct name username,'Y' no_exp from sys.exu8usr)
 using(username)
left outer join (select distinct name username,'Y' no_sby from system.logstdby$skip_support where action in (0,-1))
 using(username)
left outer join (select distinct user_name username,'Y' default_password from sys.default_pwd$)
 using(username)
left outer join (select schema_name username,'Y' sysaux,decode(count(*),1,min(occupant_desc)) occupant_desc from v$sysaux_occupants group by schema_name)
 using(username)
order by created,username;

and the result, ordered by creation date so that you can check which users were created by the database creation:

 
CREATEDUSERORACLE
MAINTAINEDCOM-
MONNO
EXPNO
EXPDPNO
SBYDEF
PWDSYS
AUX 28-FEB-14 08:25:02 AUDSYS Y YES Y Y Y Y Y 28-FEB-14 08:25:02 SYS Y YES Y Y Y Y Y 28-FEB-14 08:25:02 SYSBACKUP Y YES   Y Y Y   28-FEB-14 08:25:02 SYSDG Y YES   Y Y Y   28-FEB-14 08:25:02 SYSKM Y YES   Y Y Y   28-FEB-14 08:25:02 SYSTEM Y YES Y   Y Y Y 28-FEB-14 08:25:05 OUTLN Y YES Y   Y Y   28-FEB-14 08:29:33 GSMADMIN_INTERNAL Y YES   Y Y Y   28-FEB-14 08:29:33 GSMUSER Y YES   Y Y Y   28-FEB-14 08:29:43 DIP Y YES   Y Y Y   28-FEB-14 08:30:39 XS$NULL Y YES   Y Y Y   28-FEB-14 08:31:12 ORACLE_OCM Y YES   Y Y Y   28-FEB-14 08:39:55 DBSNMP Y YES   Y Y Y Y 28-FEB-14 08:39:56 APPQOSSYS Y YES   Y Y Y   28-FEB-14 08:40:03 ANONYMOUS Y YES   Y Y Y   28-FEB-14 08:40:03 XDB Y YES   Y Y Y Y 28-FEB-14 08:44:29 GSMCATUSER Y YES   Y Y Y   28-FEB-14 08:53:38 WMSYS Y YES   Y Y Y Y 28-FEB-14 08:55:31 OJVMSYS Y YES   Y Y Y   28-FEB-14 08:59:58 CTXSYS Y YES   Y Y Y Y 28-FEB-14 09:00:44 MDSYS Y YES   Y Y Y Y 28-FEB-14 09:00:44 ORDDATA Y YES   Y Y Y Y 28-FEB-14 09:00:44 ORDPLUGINS Y YES   Y Y Y Y 28-FEB-14 09:00:44 ORDSYS Y YES   Y Y Y Y 28-FEB-14 09:00:44 SI_INFORMTN_SCHEMA Y YES   Y Y Y Y 28-FEB-14 09:09:48 OLAPSYS Y YES   Y Y Y Y 28-FEB-14 09:10:17 MDDATA Y YES Y   Y Y   28-FEB-14 09:15:09 SPATIAL_WFS_ADMIN_USR Y YES Y   Y Y   28-FEB-14 09:15:13 SPATIAL_CSW_ADMIN_USR Y YES Y   Y Y   28-FEB-14 09:20:00 LBACSYS Y YES   Y Y Y   28-FEB-14 09:20:16 APEX_040200 Y YES       Y   28-FEB-14 09:20:16 APEX_PUBLIC_USER Y YES Y     Y   28-FEB-14 09:20:16 FLOWS_FILES Y YES       Y   28-FEB-14 09:45:17 DVF Y YES   Y Y Y   28-FEB-14 09:45:17 DVSYS Y YES   Y Y Y   21-MAR-14 18:15:19 FRANCK N NO Y         09-APR-14 20:33:34 RMAN N NO Y     Y   11-APR-14 09:04:55 DEMO N NO Y     Y   23-APR-14 20:53:09 HR N NO Y   Y Y   23-APR-14 20:53:09 IX N NO Y   Y Y   23-APR-14 20:53:09 OE N NO Y   Y Y   23-APR-14 20:53:09 PM N NO Y   Y Y   23-APR-14 20:53:09 SH N NO Y   Y Y   25-APR-14 21:26:33 SQLTXADMIN N NO Y         25-APR-14 21:26:33 SQLTXPLAIN N NO Y         27-MAY-14 21:48:24 SCOTT N NO Y   Y Y  

 

So you see that the 12c columns are highly reliable. They include all users that have been created during the database creatio, but do not include the users that were created afterwards.

When not in 12c, the exclusion list coming from DataPump is quite good, but not exhaustive.

Sometimes the most useful features are not those that change the future of database, but rather those little things that make life easier.

In DBA_USERS, we have two very useful new columns: ORACLE_MAINTAINED and LAST_LOGIN. That is a great improvement.

How to avoid Failover Cluster with PowerShell scripting

Wed, 2014-06-04 20:15

One of my colleague asked me some days ago if I could create a PowerShell script to get rid from Windows Server Failover Cluster. The reason is that it has, in some specific cases, the bad habit to failover a resource or a service even when we don't want it. To be honest, I use a lot the Failover Cluster feature of Windows Server without any problems as a SQL Server DBA, but for this specific case, I did not find a successful configuration.

Here, we are using Failover Cluster to provide a Virtual IP address for a database using Dbvisit Standby. The database is open only on one node and the switchover or failover operation is performed by hand so we want to prevent failover of the Virtual IP resource to avoid redirecting client connection to a database that is not open.

At one of our clients, we have a Windows Server 2008 R2 cluster with two nodes and a FileShare. A Client Access Point has been provided as a service for client connections and this service must not failover automatically in any cases. For some reasons, this service failovers and I cannot avoid it even with special configuration settings.

For a solution to this problem, I propose to create a PowerShell script which will create a new IP address attached to the Network IPv4 interface. This script will read a configuration file to collect informations about the IP address like network address mask, network interface name, IP address, nodes where to start and stop the IP address, etc.

Here is the format of our configuration file:

#------------------------------------------------------------------------------
# Configuration file for VIP management of databases
#------------------------------------------------------------------------------
# Configuration format :
#
# SID:VIP_ADR:VIP_MASK:VIP_IF:
#
# SID            : Oracle SID for which the VIP is configured - mandatory
# VIP_ADR     : Address of the VIP - mandatory
# VIP_MASK   : VIP Network address Mask - mandatory
# VIP_IF         : Network interface to attach the VIP (i.e Local Area Connection) - mandatory
# VIP_LSNR    : VIP Listener - optional
# VIP_Node1   : Name of Node 1 - mandatory
# VIP_Node2   : Name of Node 2 - mandatory
#
# Note :
#
# The usage of parameters delimiters allows to have potentially empty (not
# defined parameters)
#
#
# How to call the script :
#
# .CreateIPAddress.ps1 'Start' 'DBITEST' [-F]
#
# Param 1: "Start" or "Stop" - mandatory
# Param 2: VIP Address name - mandatory
# Param 3: -F to force creation of the VIP Address locally even if it is not possible to check if the VIP Address exits on the second node - optional
#
#------------------------------------------------------------------------------
# Example :
# DBITEST:192.168.22.190:255.255.255.0:Local Area Connection::test1:test2

In this blog, I will share how the script works step by step and what are the components/commands I had to learn about to create an IP on a network interface.

First of all, this PowerShell script uses the cmdlet Invoke-Command which uses Windows Remote Management (WinRM). If WinRM is not configured you can enable the WS-Management protocol on the local computer and set up the default configuration for remote management with the following command: Winrm quickconfig.

You need also to change the execution policy in your PowerShell screen with Set-ExecutionPolicy Unrestricted to allow script execution. You should also open your PowerShell screen with the Run As Administrator option.

b2ap3_thumbnail_SetPolicy.jpg

The first thing I do is to clear my screen:

b2ap3_thumbnail_screen1.jpg

Now, I have to check if I receive the parameter I need for my script:

b2ap3_thumbnail_screen2.jpg

I have initialized my two mandatory parameters and perhaps a third one which is optional. It is time to read where my configuration file is located, test this location and initialize the variables.

b2ap3_thumbnail_screen3.jpg

I am able now to read my configuration file sequentially to find my VIP Address. I will test first character of each line to avoid comment line and when I will find a non-comment line, check the first parameter of the line to test if it is equal to my VIP Address enter into the command line.

b2ap3_thumbnail_screen4.jpg

I have found my VIP Address in my configuration file, I will now split my configuration line to collect all informations I need and connect to my second node to get back the different IP Addresses attached to Network Adapters.

If the second node doesn't respond we stop the script to avoid to create a local IP Address which already exists on the second node. But if the optional parameter "-F" has been entered we force the creation.

b2ap3_thumbnail_screen5.jpg

If we run the command "Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter IPEnabled=TRUE -ComputerName $node2 -erroraction stop", we have a list of each Network Adapter with its IP Addresses associated.

b2ap3_thumbnail_screen6.jpg

We have now to search in the different lines if our VIP Address exists. If we find it, we have to delete this IP Address and if it doesn't exist, we should print a message.

b2ap3_thumbnail_screen7.jpg

For the moment, we have to check remotely if our IP Address existed on the remote server and if it was the case we have to delete this IP Address.

Now, based on our parameter, we will stop or start this IP Address locally.

b2ap3_thumbnail_screen8.jpg

Our VIP address is now started or stopped locally depending on the defined parameters. Finally, if we have not found the VIP Address in the configuration file, an error will be displayed and the script ends.

b2ap3_thumbnail_screen9.jpg

At present, we have a local VIP Address where the client can come to connect. If our node goes down for whatever reason when it comes back, our VIP address will by always in the same node. If we want to change for node 1 to node 2, we just have to run our script on node 2 and go for the parameter start. This will stop the IP Address on node 1 and start the IP Address on node 2.

I hope this script and the different functions I have shown here were able to help you.