Oracle Self-Service Kit : Gimme the details (part 1)
This is the first of two posts getting into more details about the “Oracle Server Self-Service Kit”. It goes through 2 sample uses, to highlight how the solution works and what the outputs are.
Table of content of the full series
- Introduction post
- Overview and scenarios
- Download link
- What you get, and how each deployment type is handled
- Supported versions
- Looking ahead
- Gimme the details (part 1)– this post
- Sample execution #1 : Requesting a new dedicated Oracle database
- Sample execution #2 : Requesting a new schema on a shared environment
- Gimme the details (part 2)
- More details on the Runbooks
- What’s in the VMM Service Template?
- What do I get if I use the Service Manager integration?
- Using the package : Installation and configuration
Sample execution #1 : Requesting a new dedicated Oracle database
(Note : This specific scenario is also the one outlined in this video ).
It all starts with the service request (optional integration with Service Manager):
The end to end process Runbook then goes through that branch, to successively deploy a new virtual machine (through VMM, including the OS and Oracle database software only), deploy a new database, connect to the database to collect diagnostics data, and notify the user:
This is the Runbook handling the actual new server deployment:
Since the Oracle Database “farm” already existed, the service is just being scaled out to accommodate for a new dedicated server, which will then host the database software and the database:
During the scripts being run by VMM, we can see the response files being copied and modified (notice how the timestamps are close to the timestamp of the folders copied just before). These response files are deleted after the installation and configuration.
The log file shows all the details (by default, this is also logged in the Orchestrator events):
A notification email is then being sent to the user. It includes details on the new database and its server location, the SYSTEM password, and the output from LNSRCTL/SQLPLUS commands:
Sample execution #2 : Requesting a new schema on a shared environment
First, we start with the service request:
This time, the end to process Runbook goes through that branch:
Placement is determined by this Runbook, which is basically an “empty shell” returning a global variable. It has been designed as a full subroutine, so you can choose to customize it as needed, to return something computed in the Runbook, rather than the variable:
Once placement has run, actual schema deployment subroutine looks like this – it creates or reuse the database on the determined server:
In this case, since it is the first schema in the shared database, the database needed to be created first, as the log shows:
When the database and the schema have been created, the user receives a notification, with details and diagnostics:
The full log shows all the steps:
