Re: Opinion on change control for DBA scripts
- From: Dba DBA <oracledbaquestions@xxxxxxxxx>
- Date: Thu, 27 Jun 2013 11:53:28 -0400
I like it when we use SVN or some change control tool directly on the unix
boxes. This way we can get at what we need easily. This is particularly
useful when you have clustered file systems. So you can mount many servers
to the same file system and then just go set up the cronjobs on the
different servers (you need to parameterize your scripts for the different
servers) instead of having to copy them to lots of servers (you can script
this, but its a hassle and can lead to a mess if people dont use SVN and
change stuff without checking it in). Even if you dont run them from cron
have SVN or something directly on the unix server is very nice and
convenient. You dont need all the extra whiz bang features that come with
the enterprise CM tools. Its just for the DBAs. SVN/CVS or whatever (GIT is
fine too) works just fine. Atleast now you get it plugged in and backed up
by the SAs.
as far as generic DBA scripts... we have a directory in the main change
control tool here under our DB Branch we call 'useful sql' and we check our
stuff in there and then keep notes on it so we can share the scripts. This
is mainly so the DBAs can share stuff.
Recently, I started taking some DBA scripts and turning them into views. I
found this easier than running them on the boxes. I like this because I can
use oracle comments to document them and document each field. Its very
useful when I need to give a query or something to a developer or a tester.
I generally like to use a naming convention that denotes that its not used
by the application. Lately I have been spelling out 'internal' in the view
name. The nice thing about this is I can take them with me and reuse them
from project to project. Doing the extra comments lines don't take long and
once its done, its reusable. Comments are particularly nice since most
developers/testers prefer a GUI tool. In SQL Developer when you click on a
table/view the comments come up right next to the column names. Very
convenient for them and easier for you since you don't have to explain as
much.
On Thu, Jun 27, 2013 at 10:06 AM, Patterson, Joel <jpatterson@xxxxxxxxxx>wrote:
> Holly Molly,
> It is really frustrating when you have a server that is essentially
> dedicated to oracle and the DBA is not the one that everyone should at
> least be listening to.
>
> After all isn't the number one job, protecting the companies data?
>
> Backing up the software directory is part of the overall restore plan for
> me - and that just naturally includes $ORACLE_BASE, as well as
> /var/opt/oracle, and /usr/local/bin. It just makes life easier.
>
> (tnsnames, central inventory, oraenv (I use a copy oraenvset), and so
> forth).
>
>
>
> Joel Patterson
> Database Administrator
> 904 928-2790
>
> From: Sandra Becker [mailto:sbecker6925@xxxxxxxxx]
> Sent: Thursday, June 27, 2013 9:54 AM
> To: Patterson, Joel; oracle-l
> Subject: Re: Opinion on change control for DBA scripts
>
> I used to keep my scripts on a network drive and was told to remove them
> because they took up too much space--about 300M, not big in my opinion
> considering the alternative to not backing them up. They weren't backing
> up that drive either at the time.
> My primary script directory is under $ORACLE_BASE/admin, but the sys
> admins deemed the $ORACLE_BASE path not important enough to backup. Got
> that resolved after some serious battles with IT and finally our boss
> stepping in to say "back them up on all DB servers". I make copies of
> those scripts as well as my personal DBA scripts. Trust but verify isn't
> good enough around here.
>
> Funny you should mention getting rid of those pesky data files. A couple
> of months after I started and began the massive
> backup/cleanup/monitoring/tuning tasks, the lead sys admin started deleting
> redo log files--on the production database. So we all know what happened
> next. I was working that issue when I started getting pages that one of
> the development databases had errors in the alert log. It also had
> crashed. Seems the same guy went out and decided to clean up the disk and
> deleted several data files because he didn't know what they were.
> Fortunately, I had gotten database backups working my first week on the
> job so I could restore. Fast forward 4 years. Guess what the same guy did
> again. Suffice to say I was livid. At least they call now to tell me they
> are going to clean up disk and ask if I want to save anything. I've even
> documented the mount points, directories, and file extensions never to
> touch, but still they want to clean it up. I've never worked with
> such poor sys admins prior to coming here. It's been a challenge to say
> the least.
>
>
> Sandy
> Transzap, Inc.
>
> --
> Joel Patterson
> Sr. Database Administrator | Enterprise Integration
> Phone: 904-928-2790 | Fax: 904-733-4916
> www.entint.com<http://www.entint.com/>
>
> [http://i1202.photobucket.com/albums/bb367/Entint/signaturev61.jpg]<
> http://www.entint.com/>
>
> [http://i1202.photobucket.com/albums/bb367/Entint/th_FaceBook1.jpg]<
> http://www.facebook.com/pages/Enterprise-Integration/212351215444231> [
> http://i1202.photobucket.com/albums/bb367/Entint/th_Twitter1.jpg] <
> http://twitter.com/#!/entint> [
> http://i1202.photobucket.com/albums/bb367/Entint/th_LinkedIn1.jpg] <
> http://www.linkedin.com/company/18276?trk=tyah> [
> http://i1202.photobucket.com/albums/bb367/Entint/th_YouTube1.jpg] <
> 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]
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
