Friday

Linux: Comparing packages on two servers and installing the difference.


I know this isn’t Oracle related but if you have a position in a small company like myself, chances are you are performing more than DBA duties.   We just recently hired a linux admin but he’s on vacation this week and there’s a new server to stage for a Portal environment.

In the past I have just run system-install-packages on an existing server and the new one and compare the packages.   Time consuming, error prone, etc.  Also, any patches not installed from the base system packages won’t be captured.

Given those reasons I decided to use the command line.   If you have done something similar in the past and have a better way of doing it feel free to leave a comment.

Step 1:  Get a list of RPM packages from both servers:

rpm -qa --qf "%{NAME}\n” | sort > rpms_newserver.txt

Do the same on the second server.    Since the packages may not have been installed in the same order, I pipe it to sort, otherwise I believe it would cause problems with the next step.

The rpms_newserver.txt document will have a listing of files, ex:

a2ps
acl
acpid
alacarte
.
.
.

zsh

Step 2: Put both package lists in the same directory on the new server and run the linux command diff to compare the files.

diff rpms_oldserver.txt rpms_newserver.txt | grep "<" > package_list.txt

The diff command compares two files and displays the differences.   To get a list of the lines missing from the rpms_newserver.txt file we grep for the less than arrow “<” and pipe it to a new file. 

Step 3: The package_list.txt document is in the same format as the files in step 1.   Next I used vi to insert the yum command into the file so it can be executed like a script.

Open the package_list.txt file with vi and type:

:1,$s/< /yum install -y /g

Save the document and now it looks like:

yum install -y a2ps
yum install -y alacarte
yum install -y alchemist



Step 4:

Execute the package_list.txt document:

sh package_list.txt

That’s it, once it finishes all the packages should be installed.

Tuesday

WebLogic - Smart Update patch download capability decomissioned?!

Well, this is rather unfortunate.  I am in the process of rolling out weblogic patches and found out the hard way that downloading and applying the patches via the Smart Update utility (bsu.sh) has been decomissioned!   Just a few weeks ago I posted how seamless and easy the process was to patch WebLogic.   


IMHO, this is a step backwards.  However, end of the day its not tragic.  You just have to download the patches manually via Metalink like other Oracle products and upload them to your cache directory.   Once they are in the cache directory just launch Smart Update and they will show up in the download patches section towards the bottom of the screen.  


By default the cache directory is $WL_HOME/utils/bsu/cache_dir



WebLogic Net Installers and Downloading of Patches Via Smart Update To Be Decommissioned [ID 1294294.1]



To better coordinate the distribution of patches to Oracle customers, we are planning to consolidate on My Oracle Support as the single source for patch delivery.  After the Smart Update changes are complete, you will be able to access patches and patch sets whenever you need them from the My Oracle Support Patches & Updates site.

To this end, the WebLogic Net Installers and Smart Update patch and patch set download capability will be decommissioned on June 10, 2011.

Thursday

Free SQL E-Books

Noticed an article on ReadWriteWeb a few weeks ago listing free SQL E-Books .   Not all Oracle related but a couple seem interesting.

http://www.readwriteweb.com/hack/2011/06/free-e-books-on-sql.php

Wednesday

Grid Control – Refreshing Weblogic Domains

WebLogic domains, especially SOA, tend to be very dynamic. Over time new applications may be deployed or others upgraded to the latest release, SOA partitions created/deleted, BPEL processes new/updated/deleted, etc. By default, Grid control is not aware of these changes. This can be a problem if you use grid control to centrally manage/monitor your environment. There are two options available to you:

1. Manually refresh the weblogic domain.
2. Enable Automatic Refresh

Manually refreshing a Weblogic Domain


One of the places this can be done is from the WebLogic Domain drop down menu, click on Refresh WebLogic Domain.


clip_image002

The following screen will appear, click on Continue.

clip_image004

After you click on continue target discovery will take place and a confirmation window will show how many targets were found:

clip_image006

After you click on close you’ll be brought to the assign agents screen. I’m not aware of any reason why you would want to reassign to a different agent, so I just continued by clicking on Add Targets.

clip_image008

Once you have made any changes, if necessary, above click on add targets to save the changes.

clip_image010

Automatically refreshing a Weblogic Domain


If your environment changes quite frequently you may want to enable an automatic refresh. To do this login to Grid Control, click on the Targets Table, Middleware section and select the domain you wish to make the change for.

clip_image012

Notice above that my domain was last refreshed Apr. 1st. Click on the timestamp next to WebLogic Domain Refreshed and the following window will appear:

clip_image014

After you click ok, a confirmation message will be displayed saying that it was successfully scheduled:

clip_image016

If you click on the timestamp above next to Weblogic Domain Refreshed again:

clip_image018

You can click on the job name and it will bring you to the Job Activity section of Grid Control. From here you can change the schedule of the refresh, etc.

clip_image020



Thats it, pretty simple.  I prefer to use the manual method because it provides a summary of the new or modified targets,  which you don't get by scheduling it automatically.    I haven't checked the Grid Control job logs tho to see if that information is included there.

Friday

Grid Control 11g–Blocked Agents

Today I noticed that one of my Grid Control agents was down. From the Grid Control homepage for the target:

clip_image002

I thought it had just crashed so I checked the status from the server:

[oracle@myserver bin]$ ./emctl status agent
Oracle Enterprise Manager 11g Release 1 Grid Control 11.1.0.1.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
---------------------------------------------------------------
Agent Version : 11.1.0.1.0
OMS Version : 11.1.0.1.0
Protocol Version : 11.1.0.0.0
Agent Home : /u01/app/oracle/product/grid11g/agent11g
Agent binaries : /u01/app/oracle/product/grid11g/agent11g
Agent Process ID : 29687
Parent Process ID : 29661
Agent URL : https://myserver:3872/emd/main/
Repository URL : https://myserver:4900/em/upload
Started at : 2011-06-23 02:06:56
Started by user : oracle
Last Reload : 2011-06-23 02:06:56
Last successful upload : (none)
Last attempted upload : (none)
Total Megabytes of XML files uploaded so far : 0.00
Number of XML files pending upload : 432
Size of XML files pending upload(MB) : 52.54
Available disk space on upload filesystem : 2.74%
Collection Status : Disabled by Upload Manager
Last attempted heartbeat to OMS : 2011-06-24 10:37:34
Last successful heartbeat to OMS : unknown
---------------------------------------------------------------
Agent is Running and Ready



Notice the “Last successful heartbeat to OMS” is unknown. If I try and force an upload it errors:

[oracle@myserver bin]$ ./emctl upload
Oracle Enterprise Manager 11g Release 1 Grid Control 11.1.0.1.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
---------------------------------------------------------------
EMD upload error: uploadXMLFiles skipped :: OMS version not checked yet. If this issue persists check trace files for ping to OMS related errors.



Checking the agent logs ($GRID_HOME/agent11g/sysman/log/emagent.trc):

2011-06-24 10:40:03,074 Thread-1091160384 ERROR pingManager: Did not receive valid response to ping "ERROR-Agent is blocked. Blocked reason is: Agent is out-of-sync with repository. This most likely means that the agent was reinstalled or recovered. Please contact an EM administrator to unblock the agent by performing an agent resync from the console. Please contact EM adminstrator to unblock the agent"


So the agent is out of sync with with the repository and is now blocked. I remember back in the 9i days to clean up an agent was a bit of a pain but in 11g its pretty simple. Log back into Grid Control, click on the Setup link located in the top right hand corner. Next click on the Agents link in the blue bar, followed by the Misconfiguration Alerts and Blocked Agents tab.

clip_image004

If you click on the agent itself (instead of selecting it and clicking unblock) you will be brought to the agents page shown below:

clip_image006

To resynch it click on the Agent Resynchronization button.

clip_image008

Make sure the Unblock agent on successful completion… is selected and hit continue. Once completed you may notice that the agent is still showing as unreachable. If you check via the server again you’ll notice that its working fine.  Notice the Last successful heartbeat and last successful upload rows.

[oracle@myserver bin]$ ./emctl status agent
Oracle Enterprise Manager 11g Release 1 Grid Control 11.1.0.1.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
---------------------------------------------------------------
Agent Version : 11.1.0.1.0
OMS Version : 11.1.0.1.0
Protocol Version : 11.1.0.0.0
.
.
Last successful upload : 2011-06-24 10:44:36
Total Megabytes of XML files uploaded so far : 19.37
Number of XML files pending upload : 0
Size of XML files pending upload(MB) : 0.00
Available disk space on upload filesystem : 2.76%
Last successful heartbeat to OMS : 2011-06-24 10:44:04
---------------------------------------------------------------
Agent is Running and Ready



After a short period of time it will show as up in the Grid Control Console as well.

clip_image010