Re: Installing Oracle

Comments embedded.
On Mar 1, 4:40 pm, mrdjmag..._at_aol.com wrote:
> You know, this is why developers should never be given access to the
> server.
>

No, this is why administrators and DBAs should be MUCH more careful in who has access to the 'oracle' O/S account.

> We are running ORacle 10g.  We were going to drop a database and
> recreate it on our development box.
>

A fine idea.

> Rather, a developer deleted all of the datafiles AND the software.

One wonders how this developer had access to a privileged O/S user account to begin with. Simply granting access to the server would NOT provide any developer access to delete the Oracle RDBMS software and the database files.

> I'm
> here at home with an SSH connection to work.  Can I download the
> software from Oracle's site, upload it to the server and install it
> using a response file?

I don't see why not (provided you have sufficient bandwidth), but the question still remains as to HOW this developer had such access in the first place. One tends to think it carelessness on your part.

>
> I do not have access to a GUI mode, so a response file is the only way
> to go.......
>

And had you been much more prudent in your granting of access to this server you'd still have a database and the software to run it.

> If not, is there any other way???
>
> Thanks!

I would immediately change the 'oracle' password and be much less lenient in who has access to it. Obviously this developer was able to connect as this user and create the damage you've described, Whose fault was that?

You are correct that no developer should have access to a production server, however you haven't stated anywhere that this IS a production server. Nevertheless it's also not a wise idea to pass amonst the developers the connection details for the 'oracle' O/S user account (which, obviously, has happened). I hope the 'root' password is NOT also among those the developers have been given.

You need to take a long, hard look at how you grant access to servers, because from what I've seen in this post you simply open your servers to attack from within. With such 'policies' in place you've gotten what you've deserved, the inability to control a database environment. The person or persons responsible for this debacle should be, at the least, formally reprimanded (I'm thinking termination is in order, but some may consider that a bit severe). Policies in your organization need to change, immediately, else you'll find yourself in the same position over and over again. Or you'll find yourselves out of business.

David Fitzjarrell Received on Sat Mar 01 2008 - 17:06:55 CST