DBASolved

Subscribe to  DBASolved feed  DBASolved
Helping Oracle DBAs solve problems
Updated: 3 hours 1 min ago

#GoldenGate #Cloud Service (#GGCS) … what to expect?

Mon, 2016-05-02 07:30

As I sit here working on performing some GoldenGate migrations to AWS for a client, I’ve been thinking about the glimpse of GoldenGate Cloud Service (GGCS) that was provided to me earlier this week. That glimpse has helped me define what and how GGCS is going to work within the Oracle Cloud space. Ever since this service was announced back at Oracle Open World 2015, I’ve been wanting to get my hands on this cloud product from Oracle to just better understand it. Hopefully, what I’m about to share with you will provide some insight into what to expect.

First, you will need a cloud account. If you do not have a cloud account; visit http://cloud.oracle.com and sign up for an account. This will typically be the same account you use to login to My Oracle Support (MOS).

Once you have an account and are in the cloud interface, subscribe to some services. You will need a Database Cloud Service or an Compute Cloud Service. These services will be the end points for the GGCS to point to. As part of setting up the compute node, you will need to setup SSH access with a public/private key. Once you create the GGCS instance, the same public/private key should be use to keep everything simple.

Once GGCS is made available for trial, currently it is only available through the sales team, many of us will have the opportunity to play with this. The following screen captures and comments were taken from the interface I had access to while discussing GGCS with Oracle Product Management.

Like any of the other cloud services from Oracle, once you have access to GGCS it will appear in your dashboard as available cloud services. In the figure below, GGCS is listed at the top of the services that I had access to. You will notice over on the right, there is a link called “service console”.

When you click on the service console link, you are taken to the console that is specific to GGCS. On the left hand side of the console, you will see three primary areas. The “overview” area is the important one; it provides you with all the information needed about your GGCS environment. You will see the host and port number, what version of GGCS you are running and the status of your environment.

With the environment up and running, you will want to create a new GGCS instance. This instance is created under your cloud service console. On this screen you are given information that tells you how many instances you have running with the number of OCPUs, Memory and storage for the configuration along with the public IP address. Notice the button to the right, just below Public IPs, this is the button that allows you to create a new GGCS instance. In the figure below, the instance has already been created.

Drilling down into the instance, you are taken to a page that illustrates your application nodes for GGCS. Notice that the GGCS instance actually created a compute node VM to run GoldenGate from.

With everything configured from the Oracle Cloud interface, you can now access the cloud server using the details provided (do not have current screen shots of this). Once you access the cloud server, you will find that Oracle GoldenGate has been configured for you along with a TNS entry that points to a “target” location. These items are standard template items for you to build your GoldenGate environment from. The interesting thing about this configuration is that Oracle is providing a single virtual machine (compute node) that will handle all the apply process to a database (compute node).

With the GGCS service running, you are then ready to build out your GoldenGate environment.

Like many other GoldenGate architectures, you build out the source side of the architecture like anything else. You install the GoldenGate software, build an extract, trail files and a data pump. The data pump process is then pointed to the GoldenGate Cloud Service (GGCS) instance instead of the target instance. The local trail files will be shipped to the GGCS machine. Once on the GGCS instance, the replicat would need to be configured. Part of the configuration of the replicat at this point is updating the TNSNames.ora file to point to the correct “target” compute node/database instance. The below picture illustrates this concept.

You will notice that the GGCS is setup to be an intermediary point in the cloud. This allows you to be flexible with your GoldenGate architecture in the cloud. From a single GGCS service you can run multiple replicats that can point to multiple difference cloud compute nodes; turning your GGCS into a hub that can send data to multiple cloud resources.

In talking with the Oracle Product team about GGCS, the only downside to GGCS right now is that it cannot be used for bi-directional setup or pulling data from the cloud. In essence, this is a uni-direction setup that can help you move from on-premise to cloud with minimal configuration setup needed.

Well, this is my take on GGCS as of right now. Once GGCS trials are available, I’ll try to update this post or add more posts on this topic. Until then, hope you have gain a bit of information this topic and looking forward to using GGCS.

Enjoy!!

about.me: http://about.me/dbasolved


Filed under: Cloud, Golden Gate
Categories: DBA Blogs

Veridata and boot.properties file

Mon, 2016-04-04 12:30

I’m spending some time building out an Oracle WebLogic/Veridata system at home. This is mostly for testing and general understanding purposes. One of the things I’ve noticed with the WebLogic server requires the username and password before the WebLogic server will start. After providing the name and password, the terminal window has to stay open because, closing it will kill the WebLogic server that is running. This leads to two interesting question and simple resolutions.

1. How can I automatically pass the username and password to WebLogic?
2. How to I keep WebLogic running upon closing my terminal window?

The answers to the questions are quite simple. Let’s take a look at the first question.

How can I automatically pass the username and password to WebLogic?

This is done by using a “boot.properties” file. This file needs to be placed in the security directory under the server that you want to automatically log in. In my case, I had to create a security directory and the boot.properties file under the AdminServer directory. The below steps are what I used:

$ /opt/app/oracle/product/12.2.0.1/middleware/user_projects/domains/base_domain/
$ cd ./servers
$ cd ./AdminServer
$ mkdir security
$ touch boot.properties
$ vi boot.properties

 

Once the boot.properties file is open for editing, simply put in the username and password you want the WebLogic server to use. In this case, I’m using a standard password setup.

After creating the boot.properties, file, you can go back and start the WebLogic Server and should not be prompted for a userid and password. You can see this during the startup of the Weblogic server as seen in the below image. Additionally, if you go and look at the boot.properties file, the username and password will be encrypted as well.

This same approach can be done with the Veridata components of the configuration. You just have to remember to create a security directory under the Veridata server directory as you did for the Weblogic server.

Now for the second question:

How to keep WebLogic Server running upon closing my terminal window?

With the boot.properties file in place, you can start the WebLogic/Veridata server(s) by using the “nohup” option. “Nohup” will allow you to keep the server processes running in the background.

Using these two options, you can very easily automate the starting/restarting of the WebLogic/Veridata server(s).

Enjoy!

about.me:http://about.me/dbasolved


Filed under: Golden Gate, WebLogic
Categories: DBA Blogs

Veridata and boot.properties file

Mon, 2016-04-04 12:30

I’m spending some time building out an Oracle WebLogic/Veridata system at home. This is mostly for testing and general understanding purposes. One of the things I’ve noticed with the WebLogic server requires the username and password before the WebLogic server will start. After providing the name and password, the terminal window has to stay open because, closing it will kill the WebLogic server that is running. This leads to two interesting question and simple resolutions.

1. How can I automatically pass the username and password to WebLogic?
2. How to I keep WebLogic running upon closing my terminal window?

The answers to the questions are quite simple. Let’s take a look at the first question.

How can I automatically pass the username and password to WebLogic?

This is done by using a “boot.properties” file. This file needs to be placed in the security directory under the server that you want to automatically log in. In my case, I had to create a security directory and the boot.properties file under the AdminServer directory. The below steps are what I used:

$ /opt/app/oracle/product/12.2.0.1/middleware/user_projects/domains/base_domain/
$ cd ./servers
$ cd ./AdminServer
$ mkdir security
$ touch boot.properties
$ vi boot.properties

 

Once the boot.properties file is open for editing, simply put in the username and password you want the WebLogic server to use. In this case, I’m using a standard password setup.

After creating the boot.properties, file, you can go back and start the WebLogic Server and should not be prompted for a userid and password. You can see this during the startup of the Weblogic server as seen in the below image. Additionally, if you go and look at the boot.properties file, the username and password will be encrypted as well.

This same approach can be done with the Veridata components of the configuration. You just have to remember to create a security directory under the Veridata server directory as you did for the Weblogic server.

Now for the second question:

How to keep WebLogic Server running upon closing my terminal window?

With the boot.properties file in place, you can start the WebLogic/Veridata server(s) by using the “nohup” option. “Nohup” will allow you to keep the server processes running in the background.

Using these two options, you can very easily automate the starting/restarting of the WebLogic/Veridata server(s).

Enjoy!

about.me:http://about.me/dbasolved


Filed under: Golden Gate, WebLogic
Categories: DBA Blogs

#EMd360 … OEM health checks made easy

Mon, 2016-03-14 12:01

Oracle Enterprise Manager 12c is a great tool! Now that 13c is out, it is getting even better. This post however it not really about Oracle Enterprise Manager, rather than a quick and simple health check tool that I’ve put together. With the help of of some really cool co-workers (Carlos Sierra and Mauro Pagano), I’ve put together a small diagnostic tool call EMd360.

EMd360 stands for Enterprise Manager d360. The concept behind this tool is just like other tools that have been released with the 360 concept (edb360 and sqld360); to provide a quick and easy approach to checking an environment. As with edb360 and sqld360, EMd360 is a completely free tool for anyone to use.

So, why is there a need for EMd360? It is quite simple, there are so many things that go into OEM and you get so much out of OEM it is overwhelming. As a consultant, I’ve been asked to review a lot of OEM architectures and the associated performance. A lot of this information is in the OMR and often time I’m using other tools like REPVFY and OMSVFY, plus a handful of scripts. I’ve decided to make my life (and hopefully yours) a bit easier by building EMd360.

The first (base) release of EMd360 is now live on GitHub (https://github.com/dbasolved/EMd360.git). Go and get it! Test it out!

Download

If you are interested in trying out EMd360, you can download it from GitHub.

Instructions

Download EMd360 from GitHub as a zip file
Unzip EMd360-master.zip on the OMR server and navigate to the directory where you unzipped it
Connect to the OMR using SQL*Plus and execute @emd360.sql

Options

The @emd360.sql script take two variables. You will be prompted for them if not passed on the sql command line.

Variable 1 – Server name of the Oracle Management Service (without domain names)
Variable 2 – Oracle Management Repository name (database SID)

Example:

$ sqlplus / as sysdba
SQL> @emd360 pebble oemrep

Let me know your thoughts and if there is something you would like to see in it. Every environment is different and there maybe something you are looking for that is not provided. Let me know via email or blog comment and I’ll try to get it added in the next release.

Enjoy!!!

about.me: http://about.me/dbasolved


Filed under: OEM
Categories: DBA Blogs

#EMd360 … OEM health checks made easy

Mon, 2016-03-14 12:01

Oracle Enterprise Manager 12c is a great tool! Now that 13c is out, it is getting even better. This post however it not really about Oracle Enterprise Manager, rather than a quick and simple health check tool that I’ve put together. With the help of of some really cool co-workers (Carlos Sierra and Mauro Pagano), I’ve put together a small diagnostic tool call EMd360.

EMd360 stands for Enterprise Manager d360. The concept behind this tool is just like other tools that have been released with the 360 concept (edb360 and sqld360); to provide a quick and easy approach to checking an environment. As with edb360 and sqld360, EMd360 is a completely free tool for anyone to use.

So, why is there a need for EMd360? It is quite simple, there are so many things that go into OEM and you get so much out of OEM it is overwhelming. As a consultant, I’ve been asked to review a lot of OEM architectures and the associated performance. A lot of this information is in the OMR and often time I’m using other tools like REPVFY and OMSVFY, plus a handful of scripts. I’ve decided to make my life (and hopefully yours) a bit easier by building EMd360.

The first (base) release of EMd360 is now live on GitHub (https://github.com/dbasolved/EMd360.git). Go and get it! Test it out!

Download

If you are interested in trying out EMd360, you can download it from GitHub.

Instructions

Download EMd360 from GitHub as a zip file
Unzip EMd360-master.zip on the OMR server and navigate to the directory where you unzipped it
Connect to the OMR using SQL*Plus and execute @emd360.sql

Options

The @emd360.sql script take two variables. You will be prompted for them if not passed on the sql command line.

Variable 1 – Server name of the Oracle Management Service (without domain names)
Variable 2 – Oracle Management Repository name (database SID)

Example:

$ sqlplus / as sysdbaSQL> @emd360 pebble oemrep

Let me know your thoughts and if there is something you would like to see in it. Every environment is different and there maybe something you are looking for that is not provided. Let me know via email or blog comment and I’ll try to get it added in the next release.

Enjoy!!!

about.me: http://about.me/dbasolved


Filed under: OEM
Categories: DBA Blogs

Renaming #EM12c / #EM13c Targets

Tue, 2016-03-08 09:20

Oracle Enterprise Manager is a complex piece of software that many organizations are running now. Some organizations set out with a formalized naming standard; some do not. Those who do not ofter end up identifying a naming standard later down the road and then making requests to change the names of the targets being monitored. In order to do this, there are two ways:

1. Delete and rediscover the target and rename at time of discovery
2. Change the name from the backend using EMCLI

The first way is painful to say the least, especially when you have thousands upon thousands of targets. So this post is going to focus on how to change the name from the backend using EMCLI and a few other little tips.

EMCLI is a nice tool to use. It provides two options for renaming of targets. The first option is rename_target and the second is modify_target. The rename_target option is used to rename the target on the repository side, while the modify_target option is used to rename at the agent level. Both options are required when renaming a target because the target needs to stay in-sync to retain the history of the target.

To make this process a bit more automated, I’ve created a perl script that will do the renaming for me based on information in a space delimited flat file. The script is as follows:

#!/usr/bin/perl -w
use strict;
use warnings;

##########################
#Notes
##########################
#
#To help with renaming the entity_name in the repository database,
#comment out block of code in SYSMAN.EM_TARGET from line 8028 thru 8035
#
##########################
#GLOBAL Variables
##########################
my $oem_home_bin = "";
my $time_now = localtime();
my ($variable, $sysman_pwd) = @ARGV;
my $count = 0;
my @columns;

##########################
#Main Program
##########################

open (FILE, "< $variable") or die "$!\n";
@columns = ("", 0, 0, 0);
print "\nStart time: ".$time_now."\n";
emcli_login();
while()
{
	my $line = $_;
	@columns = split(' ',$line, 4);
	rename_target(@columns);
	$count = $count+1;
} #end file read
close (FILE) or die "$!\n";
my $end_time=localtime();
print "\nNumber of changes: ".$count;
print "\nEnd time: ".$end_time."\n";
emcli_logout();

##########################
#Sub-Programs
##########################
sub emcli_login{
	print "\n";
	system($oem_home_bin.'/emcli login -username=sysman -password='.$sysman_pwd);
	system($oem_home_bin.'/emcli sync');
	print "\n";
}

sub emcli_logout{
	print "\n";
	system($oem_home_bin.'/emcli logout');
	print "\n";
}

sub rename_target{
	#Parameters
	my ($target_name, $target_type, $server_name )=@columns;
	my $mod_target;
	my $new_name;
	my $cmd;
	my $cmd1;

	if ($target_type =~ /rac_database/)
	{
		chomp($target_name);
		chomp($server_name);
		$mod_target = $target_name;
		$target_name = substr($target_name, 0, -4);
		$new_name = $target_name."_".$server_name;
		#print $new_name;
		print "\n";
		$cmd = 'emcli modify_target -name="'.$mod_target.'" -type="'.$target_type.'" -display_name="'.$new_name.'" -on_agent';
		print $cmd."\n";
		#print "\n!!!!Executing on agent side!!!!\n";
		#system($oem_home_bin.'/'.$cmd);
		$cmd1 = 'emcli rename_target -target_type="'.$target_type.'" -target_name="'.$mod_target.'" -new_target_name="'.$new_name.'"';
		print $cmd1."\n";
		#print "\n!!!!Executing on repository side!!!!\n";
		#system($oem_home_bin.'/'.$cmd);
	}
}

Notice that I’m doing the renaming at the agent side along with the repository side. Although this looks pretty simple and straight forward, I’ve found that the EMCLI command to rename (rename_target) is actually driven by the package EM_TARGET in the SYSMAN schema. There is a small set of code in this package that will prevent renaming of certain target types if they are currently being monitored and managed by OEM.

To identify what targets are managed, the following SQL can be used:

SELECT ENTITY_TYPE, ENTITY_NAME, DISPLAY_NAME FROM EM_MANAGEABLE_ENTITIES 
WHERE ENTITY_TYPE='oracle_database' and promote_status=3 and manage_status=‘2';

The SQL above will provide you with the target type (entity_type), name (entity_name), and display name (display_name). These three columns are important because they directly correlate to what you will see in OEM. About 90% of the screen in OEM use the display_name column. The other 10% of the screens use the entity_name. When you start renaming, you will want these names to match, just keep in mind they may not over the long haul.

Now, back to the code in the EM_TARGET package. When renaming targets, some target will report back that the target cannot be changed. This is due to the target already being managed by OEM. In order to by-pass this, you need to update the EM_TARGET package body and comment out a small set of code (make sure you back up the package before doing anything). The lines of code that need to be commented out are between 8028 and 8035.

-- we will implement rename of agent side targets when it is fully
     -- supported by agent
    --IF ( l_trec.manage_status = MANAGE_STATUS_MANAGED AND
    --     l_trec.emd_url IS NOT NULL) 
    --THEN
    --  raise_application_error(MGMT_GLOBAL.INVALID_PARAMS_ERR,
    --      MGMT_GLOBAL.INVALID_PARAMS_ERR||' Not allowed') ;
    --END IF ;

After commenting out these lines of code, recompile the package. Then you will be able to rename repository targets using EMCLI even though they are already managed targets. This will effect the entity_name column and allow you to update the other 10% of pages that are not immediately changed.
 
Another way to change names of targets once the EM_TARGET package has been updated, is to use SQL to make the changes.

exec sysman.em_target.rename_target(target_type, current_name, new_name, new_name);
commit;

Once the commit has happened, then the OEM pages can be refreshed and the new entity_name will be displayed.

Well, I hope this has provided you some explanation on how to change existing targets within the EM framework.

Enjoy!

about.me: http://about.me/dbasolved


Filed under: EMCLI, OEM
Categories: DBA Blogs

Renaming #EM12c / #EM13c Targets

Tue, 2016-03-08 09:20

Oracle Enterprise Manager is a complex piece of software that many organizations are running now. Some organizations set out with a formalized naming standard; some do not. Those who do not ofter end up identifying a naming standard later down the road and then making requests to change the names of the targets being monitored. In order to do this, there are two ways:

1. Delete and rediscover the target and rename at time of discovery
2. Change the name from the backend using EMCLI

The first way is painful to say the least, especially when you have thousands upon thousands of targets. So this post is going to focus on how to change the name from the backend using EMCLI and a few other little tips.

EMCLI is a nice tool to use. It provides two options for renaming of targets. The first option is rename_target and the second is modify_target. The rename_target option is used to rename the target on the repository side, while the modify_target option is used to rename at the agent level. Both options are required when renaming a target because the target needs to stay in-sync to retain the history of the target.

To make this process a bit more automated, I’ve created a perl script that will do the renaming for me based on information in a space delimited flat file. The script is as follows:

#!/usr/bin/perl -w
use strict;
use warnings;

##########################
#Notes
##########################
#
#To help with renaming the entity_name in the repository database,
#comment out block of code in SYSMAN.EM_TARGET from line 8028 thru 8035
#
##########################
#GLOBAL Variables
##########################
my $oem_home_bin = "";
my $time_now = localtime();
my ($variable, $sysman_pwd) = @ARGV;
my $count = 0;
my @columns;

##########################
#Main Program
##########################

open (FILE, "< $variable") or die "$!\n";
@columns = ("", 0, 0, 0);
print "\nStart time: ".$time_now."\n";
emcli_login();
while()
{
	my $line = $_;
	@columns = split(' ',$line, 4);
	rename_target(@columns);
	$count = $count+1;
} #end file read
close (FILE) or die "$!\n";
my $end_time=localtime();
print "\nNumber of changes: ".$count;
print "\nEnd time: ".$end_time."\n";
emcli_logout();

##########################
#Sub-Programs
##########################
sub emcli_login{
	print "\n";
	system($oem_home_bin.'/emcli login -username=sysman -password='.$sysman_pwd);
	system($oem_home_bin.'/emcli sync');
	print "\n";
}

sub emcli_logout{
	print "\n";
	system($oem_home_bin.'/emcli logout');
	print "\n";
}

sub rename_target{
	#Parameters
	my ($target_name, $target_type, $server_name )=@columns;
	my $mod_target;
	my $new_name;
	my $cmd;
	my $cmd1;

	if ($target_type =~ /rac_database/)
	{
		chomp($target_name);
		chomp($server_name);
		$mod_target = $target_name;
		$target_name = substr($target_name, 0, -4);
		$new_name = $target_name."_".$server_name;
		#print $new_name;
		print "\n";
		$cmd = 'emcli modify_target -name="'.$mod_target.'" -type="'.$target_type.'" -display_name="'.$new_name.'" -on_agent';
		print $cmd."\n";
		#print "\n!!!!Executing on agent side!!!!\n";
		#system($oem_home_bin.'/'.$cmd);
		$cmd1 = 'emcli rename_target -target_type="'.$target_type.'" -target_name="'.$mod_target.'" -new_target_name="'.$new_name.'"';
		print $cmd1."\n";
		#print "\n!!!!Executing on repository side!!!!\n";
		#system($oem_home_bin.'/'.$cmd);
	}
}

Notice that I’m doing the renaming at the agent side along with the repository side. Although this looks pretty simple and straight forward, I’ve found that the EMCLI command to rename (rename_target) is actually driven by the package EM_TARGET in the SYSMAN schema. There is a small set of code in this package that will prevent renaming of certain target types if they are currently being monitored and managed by OEM.

To identify what targets are managed, the following SQL can be used:

SELECT ENTITY_TYPE, ENTITY_NAME, DISPLAY_NAME FROM EM_MANAGEABLE_ENTITIES 
WHERE ENTITY_TYPE='oracle_database' and promote_status=3 and manage_status=‘2';

The SQL above will provide you with the target type (entity_type), name (entity_name), and display name (display_name). These three columns are important because they directly correlate to what you will see in OEM. About 90% of the screen in OEM use the display_name column. The other 10% of the screens use the entity_name. When you start renaming, you will want these names to match, just keep in mind they may not over the long haul.

Now, back to the code in the EM_TARGET package. When renaming targets, some target will report back that the target cannot be changed. This is due to the target already being managed by OEM. In order to by-pass this, you need to update the EM_TARGET package body and comment out a small set of code (make sure you back up the package before doing anything). The lines of code that need to be commented out are between 8028 and 8035.

-- we will implement rename of agent side targets when it is fully
     -- supported by agent
    --IF ( l_trec.manage_status = MANAGE_STATUS_MANAGED AND
    --     l_trec.emd_url IS NOT NULL) 
    --THEN
    --  raise_application_error(MGMT_GLOBAL.INVALID_PARAMS_ERR,
    --      MGMT_GLOBAL.INVALID_PARAMS_ERR||' Not allowed') ;
    --END IF ;

After commenting out these lines of code, recompile the package. Then you will be able to rename repository targets using EMCLI even though they are already managed targets. This will effect the entity_name column and allow you to update the other 10% of pages that are not immediately changed.
 
Another way to change names of targets once the EM_TARGET package has been updated, is to use SQL to make the changes.

exec sysman.em_target.rename_target(target_type, current_name, new_name, new_name);
commit;

Once the commit has happened, then the OEM pages can be refreshed and the new entity_name will be displayed.

Well, I hope this has provided you some explanation on how to change existing targets within the EM framework.

Enjoy!

about.me: http://about.me/dbasolved


Filed under: EMCLI, OEM
Categories: DBA Blogs