Who can log in during restricted session?

Couple of quick statements to identify potentially problem users during an upgrade or patch:

select grantee from dba_sys_privs where privilege = 'RESTRICTED SESSION'

Some of the results will be roles... for example, the dba role will be in that result set.

You'll need to track down who has the dba role as well:

select grantee from dba_role_privs where granted_role = 'DBA';

AT&T SMTP issue

In an effort to cut down on spam, AT&T by default blocks pretty much all external smtp servers.

You can remove this block by submitting an abuse report here: http://helpme.att.net/servabuse.php

Choose Opt-out Port 25 from the abuse type list.

They recommend that mail hosts use an authenticated port 587 instead of 25, so you wouldn't need to worry about the port block.

(As for reaching work smtp from at&t? You can always use vpn, no?)

Telnet in windows vista?

Looks like the telnet client isn't installed by default with vista.

Try typing telnet from the command line. D'oh!

Fix? Start >> Control Panel >> Programs >> Turn Windows features on or off

Find Telnet Client in the client list, check the box to install and click OK.

Now from the command prompt, telnet works as expected.

Oracle inventory problems

Had an interesting problem happen today while applying cpu2007apr to our grid control infrastructure.

After applying the cpu to the em app server, I started work on the patches, and ran into a brick wall while patching a db server.

A simple opatch lsinventory would fail, showing one of the homes that wasn't the agent home, then spitting out this set of errors:

Inventory load failed... OPatch cannot load inventory for the given Oracle Home.
Possible causes are:
   Oracle Home dir. path does not exist in Central Inventory
   Oracle Home is a symbolic link
   Oracle Home inventory is corrupted
LsInventorySession failed: OracleHomeInventory::load() gets null oracleHomeInfo

OPatch failed with error code 73

Oh no! The inventory is corrupted! Actually, it's not at all corrupted, I just did something stupid during the initial install of this box and haven't corrected it yet.

I've got two oraInventory's on this box. Which means I'm going to need to be very specific when identifying which oraInst.loc I'm using.

In this situation, I checked in the AGENT_HOME/oraInst.loc to locate the missing inventory, and then used that in the invPtrLoc command below:

[oracle@omsdb:/usr/users/oracle]# opatch lsinventory -detail \ 
     -invPtrLoc /u01/app/oracle/product/agent10g/oraInst.loc 

What the heck is ocssd.bin?

On a 10.1.0.5 db system we were patching, we saw a process we didn't expect to be running.

[oracle@omsdb:/u01/app/oracle/stage/patch/cpu2007apr/5901877]# ps -ef | grep ora
  oracle   486     1  0   Mar 21 ?        0:03 /u01/app/oracle/product/10.1.0/bin/ocssd.bin
 jmorast 12755 12753  0 10:41:35 ?        0:00 /usr/local/sbin/sshd -R

A slight bit of research reveals the following from Frank Naude.

It appears this process is part of Oracle Cluster Synch Service Daemon, even though RAC and ASM aren't in use.

Solve the immediate issue by running this command from root:

/etc/init.d/init.cssd stop

A permanent fix is to comment out the following line in /etc/inittab and reboot the
server:

h1:35:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1

Not your grandma's sqlplus

Andy Campbell has a great post about adding color to SQL*Plus. Now, I'm not one to go out and make changes like this to production without using them for 6 months or so... but...

Does SQL*Plus, much like vi (or 6, as the cool kids like to call it) become our bread and butter because of or rather in spite of it's stability (or perhaps one should look at it as lack of improvements) over time?

I made a point of becoming an expert with vi early in my career, and I've never regretted that choice. Much like the other basic components of living on a unix platform, it does it's job quickly and efficiently, with bells and whistles sacrificed in the name of speed and stability over time.

SQL*Plus... I suppose the biggest issue here is that new versions of Oracle rarely cause issue for scripts (can I get a shout out for svrmgrl?). Since that stability is a requirement (svrmgrl scripts were the ones that were broke, not ones involving sqlplus anyhow), change is going to arrive at a glacial pace.

There are some people attempting to implement newer feature sets. There are a few different replacements for sqlplus, I don't consider any of these ready for my production use.

So -- I'll go ahead and say it. Without a relatively large amount of customization, sqlplus is a pain in the ass. I guess vi is not a fair comparison for what I'm thinking. Sqlplus is a shell, vi isn't. Perhaps a better comparison is the bourne shell since both are evolving at about the same rate, both are about as irritating.

I suppose the point that I'm every so slowly arriving at, is that early in my career I shifted from bourne (and csh) to bash (I still hate you, HP/UX 10) and never looked back. Sure there's a script here or there that I've used bourne or ksh or csh with, but the majority of my daily work is in bash. Perhaps it's time to dig through the replacements I mentioned earlier and see if they're ready to be prime time players.

Or... do we keep tweaking sqlplus?

Lots of invalid objects

Here's a nice eyebrow raiser you'll occasionally see during installing CPU's or application upgrades. It probably shouldn't ever happen, right?

SQL> select count(*) from dba_objects where status <> 'INVALID';

 COUNT(*)
----------
    28763

So what's the problem?