RE: Opinion on change control for DBA scripts

From: Patterson, Joel <jpatterson_at_entint.com>
Date: Thu, 27 Jun 2013 08:51:18 -0400
Message-ID: <C1117B1AA0340645894671E09A7891F71512563EF3_at_EIHQEXVM2.ei.local>



I have what I call a Gold directory on a network drive. Mostly it contains the scripts that I keep on the unix boxes. Every box is laid out the same way, and a copy is on every server.

I never have any issue with my sysadmins not backing up the directories I want. Essentaily the scripts are off of $ORACLE_BASE/admin, and some notes and documents on a backup device with the same directory from every server.

I have been using ftp.exe (classic ftp) from Exceed. (I have not upgraded because I do not know if it exists in the newer version). I can open up a 'profile' and drag my script from one computer to another and also to my gold directory on the network drive. Each particular directory has its own profile, like /var/opt/oracle open at the same time on every server.

For all my other 'my dba' scripts I always keep them on a network drive, and that drive is also backed up. The library is so big now, I don't even know everything that is there :)

One thing you can always count on is that hardware has a 100% chance of failure, (hence redundancy), but people that come after you and 'clean up' your stuff -- is unprofessional and discourteous. Especially the second time. It shows arrogance and lack of respect -- why can't they ask? You can only hope they don't get rid of some of the pesky little files in the dba_data_files.file_name directories.

Joel Patterson
Database Administrator
904 928-2790

--
Joel Patterson
Sr. Database Administrator | Enterprise Integration
Phone: 904-928-2790 | Fax: 904-733-4916
http://www.entint.com/

http://www.entint.com/

http://www.facebook.com/pages/Enterprise-Integration/212351215444231 http://twitter.com/#!/entint http://www.linkedin.com/company/18276?trk=tyah http://www.youtube.com/user/ValueofIT

This message (and any associated files) is intended only for the use
of the addressee and may contain information that is confidential,
subject to copyright or constitutes a trade secret. If you are not the
intended recipient, you are hereby notified that any dissemination,
copying or distribution of this message, or files associated with this
message, is strictly prohibited. If you have received this message in
error, please notify us immediately by replying to the message and
deleting it from your computer. Messages sent to and from us may be
monitored. Any views or opinions presented are solely those of the
author and do not necessarily represent those of the company. [v.1.1]

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Sandra Becker
Sent: Wednesday, June 26, 2013 4:40 PM
To: Jeremy Schneider; oracle-l
Subject: Re: Opinion on change control for DBA scripts

Jeremy,
You bring up some good points I hadn't considered before.  As the only DBA at the company, I don't have to worry about other people changing my scripts and I always make a copy before I do any edits.  Something I learned to do 20 years ago when I first became a DBA.  None of the scripts I lost were critical to the operation of the company, only to me as the DBA.  They use svn for the application code.  I don't have access to svn though.  In the past I've been told it was only for application code, not the silly little scripts a DBA would write.  Development handles all the control of svn.

In 7 years here the only issue with my scripts was IT not backing up my script directories on the database servers.  In fact, they didn't backup anything on my database servers.  (My DB backups get written to disk on another server so they're safe.  And yes, I have tested restores from the
backups.)  Their thinking was that I could always copy what I needed from another database server because all databases are the same.  Right.  And pigs fly too.

Shortly after the second time IT wiped out my scripts (tracked it down to them doing some disk cleanup), they were told not to touch anything on database servers without checking with me first and to start backing up every directory I designated immediately.  I even tested to see if they could restore a file for me and it was successful.  However, they recently fired the only sys admin who really knew how to retrieve anything from tape.  Hmmm...  I copy all my scripts to a thumb drive on a regular basis--lack of trust issue on my part.  Once bitten, twice shy; twice bitten thrice shy.

Sandy


On Wed, Jun 26, 2013 at 2:08 PM, Jeremy Schneider < jeremy.schneider_at_ardentperf.com> wrote:


> When I started at the company where I now work, DBA scripts were
> copied everywhere and would be updated on the fly. One guy was kindof
> the main owner and would generally keep stuff merged and in his head
> he usually knew which server(s) had the latest copy of some particular
> script. But sometimes it took some looking around. This has
> generally worked fine in the past, but now we're in a fairly rapid
> growth phase and I decided it was time to improve our processes in
> this area. I started a conversation that included architecture, dev, and ops in addition to our engineering group...
> selected svn as the most appropriate system (based on history and
> existing systems and skills and roadmaps within the company) and setup
> a repository for our group - now all scripts are in change control and
> I am much happier with the many benefits of this. I know where the
> "authoritative" copy is, I can view history showing who changed which
> lines if something stops working and I can revert changes, and it
> provided a foundation for automatic deployment and continual updating on all servers.
>
> It's a favorite issue for me personally, I feel somewhat strongly that
> most DBAs are doing software engineering with the thousands of code
> they maintain in scripts yet completely ignoring the entire field and
> deep knowledge that's available. Not that you always need to use a
> heavy-weight change control system or SDLC process. But treat that
> stuff like the
> *code* that it is, and ask the same set of questions that any decent
> software engineering shop would ask about the appropriate way to treat
> your particular code base. The most important question isn't "do you
> check your script in" but rather the most important questions are
> higher-level... what situations do you need to be protected from and how is that done.
> (backups? history? central authority? traceability?) A shared script
> library that multiple people maintain has different requirements than
> a personal script library. Scripts that you want to share with the
> community have different requirements than scripts which must remain
> proprietary and confidential. Scripts used occasionally by one person
> have different requirements than scripts maintained by the engineering
> team and used heavily by another operations team. Some scripts are
> called by other scripts or processes - and these may need well-defined
> interfaces and maintain compatible behavior across updates. Your
> scripts might be copied to two servers or they might be copied to two
> thousand. Everything depends on your particular case.
>
> Just a few thoughts...
>
> -J
>
>
> --
> http://about.me/jeremy_schneider
>
>
> On Wed, Jun 26, 2013 at 2:41 PM, Andrew Kerber <andrew.kerber_at_gmail.com>wrote:
>
>> I keep copies of everything, but I have occasionally had to do formal
>> change control (ie, keep a source library, comment all changes, move
>> through test/dev/prod process) on some scripts. Basically I always
>> just copied whatever development was using I had to. But disk space
>> usage records is not a dba job, its a systems job.
>>
>>
-- Sandy Transzap, Inc. -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l
Received on Thu Jun 27 2013 - 14:51:18 CEST

Original text of this message