Hello and scripting question

[mikehern]

Hello,
I have been designated the backup DBA and tasked to study all of our Linux scripts.

Can anyone tell me how to get started.
Where can i learn about scripting and Progress scripts.

We have start/stop backup/restore ......


Mike Hernandez

 

[TomBascom]

I would start with the "start" script...

Is there any documentation of this environment? Or do you get to create that too?

 

[mikehern]

The scripts already exist.
I need to understand them so that i can use them amd make changes in the future.

Here is an example of a script to restore our test environment from the production dbL:

DLC=/eis/dlc/91e
export DLC
DB=test; export DB
DBSET=testeb2; export DBSET
DBS=/dbs/$DB/prod; export DBS
BKUP=/backup/prodeb2; export BKUP
SCRIPT=/eis/scripts/backup/$DB; export SCRIPT
#EMAIL Stuff
read -r SRCBOX </prod1/dbhname.txt; export SRCBOX
MSG="The Production DBs have been restored to $DBSET on $SRCBOX "; export MSG
EMAIL=' i took this since it has company email addresses'; export EMAIL
# End Email Stuff
echo "stopping database set...."
/eis/scripts/startup/stop $DBSET
echo "backing up hard code entries for database set...."
$DLC/bin/pro -b $DBS'1'/$DB'webeb2' -U batch -P bat2run -p $SCRIPT/restprogs/'predel'$DB'.p' >$SCRIPT/predel.out
echo "restoring production to $DBSET database set...."
$DLC/bin/prorest $DBS'3'/'adm'$DB $BKUP/admprod-bak </prod1/yesin
$DLC/bin/prorest $DBS'3'/hlp$DB $BKUP/hlpprod-bak </prod1/yesin
$DLC/bin/prorest $DBS'2'/$DB'cateb2' $BKUP/cateb2-bak </prod1/yesin
$DLC/bin/prorest $DBS'1'/$DB'eb2' $BKUP/prodeb2-bak </prod1/yesin
$DLC/bin/prorest $DBS'1'/$DB'webeb2' /backup/webeb2/webeb2-bak </prod1/yesin
echo "Cleaning production data out of $DBSET database set...."
$SCRIPT/$DB'clean.ksh'
echo "done with $DBSET restore from production"
mailx -s "$MSG" $EMAIL </prod1/yesin

 

[TomBascom]

I meant that I would start working on understanding the scripts by starting with the "start" script. And if there is any documentation available I'd read that while looking at the scripts. (The Progress documentation is sure to be helpful too.)

I'm unclear on what it is that you are looking for from this forum. Do you need help reading and understanding shell scripts? Or do you need help understanding what the Progress commands do? Or are you looking for ideas on improving the scripts that you have? In any event specific questions will go a long ways towards useful answers. Open ended questions (or statements that aren't even questions) probably aren't going to generate much of a response.

 

[mikehern]

Sorry for being so unclear.

I need to know how to read and understand the scripts.

No documentation exists.

I am looking for a source on Linux scripting for Progess.

I am a programmer and have not done any Progress DBA work in years.

 

[TomBascom]

Well I'm away from home so my bookshelf isn't handy but any decent bookstore is going to have a couple of reasonably good Unix shell scripting books available.

Thumb through them and make sure that you get one that is at the right level and you should be on your way.

 

[TomBascom]

Apparently I'm a glutton for punishment tonight :awink:

"#" starts a comment in a shell script -- everything from the hash to the end of the line is a comment.

#!/bin/ksh
#
# Scripts should start with something like the first line -- it tells
# UNIX what shell to run the script with.
#
# It is, of course, also always good to comment your code and put in a
# header comment that tells people what the script is supposedly doing
#
# In particular it is a very good idea to document any parameters that
# might be passed in to your script.  Shell script parameters are numbered
# like so:
#
# $0 = the script name
# $1 = the first parameter
# $2 = the second parameter
# $n = the Nth parameter
# $* = all parameters

DLC=/eis/dlc/91e          # A variable named DLC is being assigned a value.
export DLC                  # Exporting the variable makes it available to
                                # sub shells  -- it does not make it available to the
                                # parent shell.  Note that you export variables
                                # WITHOUT using a "$"; you are exporting the
                                # variable, not its value.

DB=test; export DB       # The ";" ends one command and starts another.
                                 # this allows you to put two commands on one
                                 # line.  It's a very common thing to do with export.

DBSET=testeb2; export DBSET
DBS=/dbs/$DB/prod; export DBS    # The DBS variable is being set based, in
                                               # part, on the value of the DB variable.

# It is generally better to get into the habit of writing this sort of thing as:
#
#   DBS=/dbs/${DB}/prod; export DBS
#
# The braces help to delimit the variable from the surrounding text
# preventing unfortunate naming accidents that might occur if it were
# more like this:
#
#   DBS=/$DBxyz/prod l export DBS
#
# If there happens to be a variable named DBxyz you may not get the
# result that you expect...


BKUP=/backup/prodeb2; export BKUP
SCRIPT=/eis/scripts/backup/$DB; export SCRIPT

# The variables above are probably commonly used in many scripts.  If you
# ever need to change them (like if you upgrade someday) you'll need to
# track them down in a lot of places.  A good way to avoid this is to create
# a standard environment script and to "dot" that script in each your work
# scripts like so:
#
#    . /eis/scripts/progress.sh
#
# Note that there is a space between the "." and the environment script
# name.  This causes the environment script to be executed in the current
# context rather than a sub-shell which allows the variables to be set
# properly and made available to your working script and makes it so that
# you only need to modify them in a single place if something changes.

#EMAIL Stuff
read -r SRCBOX </prod1/dbhname.txt; export SRCBOX

# The "read" command prompts for the value of SRCBOX
# "<" means that the input is being taken from /prod1/dbhname.txt
# If there had been no "<" then the terminal would be the source of input.
# IOW you would need to type a response.

MSG="The Production DBs have been restored to $DBSET on $SRCBOX "; 

# Again the variables inside the string would be better written with ${VAR}
# syntax.

export MSG
EMAIL=' i took this since it has company email addresses'; export EMAIL
# End Email Stuff
echo "stopping database set...."

# The "echo" command writes to the output destination (probably the
# user's screen).

/eis/scripts/startup/stop $DBSET
echo "backing up hard code entries for database set...."
$DLC/bin/pro -b $DBS'1'/$DB'webeb2' -U batch -P bat2run -p $SCRIPT/restprogs/'predel'$DB'.p' >$SCRIPT/predel.out
echo "restoring production to $DBSET database set...."

# Input is being taken from "yesin" which, I'm guessing, is a file containing
# lines of "y".  A better way to do this might be to leverage the "yes"
# command and a pipe like so:
#
#   yes | $DLC/bin/prorest $DBS'3'/'adm'$DB $BKUP/admprod-bak
#
# Also if the backups consist of multiple volumes the "yesin"
# file should contain:
#
#  y
#  volume2-bak
#  volume3-bak
#
# and so forth (with full path names used).
#
# I have a suspicion that this file has all possible extent names for all
# databases and that it is abusing prorests willingness to keep trying
# extents until it finds the right one.

$DLC/bin/prorest $DBS'3'/'adm'$DB $BKUP/admprod-bak </prod1/yesin
$DLC/bin/prorest $DBS'3'/hlp$DB $BKUP/hlpprod-bak </prod1/yesin
$DLC/bin/prorest $DBS'2'/$DB'cateb2' $BKUP/cateb2-bak </prod1/yesin
$DLC/bin/prorest $DBS'1'/$DB'eb2' $BKUP/prodeb2-bak </prod1/yesin
$DLC/bin/prorest $DBS'1'/$DB'webeb2' /backup/webeb2/webeb2-bak </prod1/yesin
echo "Cleaning production data out of $DBSET database set...."

# Running another script -- this script might depend on values that were
# exported above

$SCRIPT/$DB'clean.ksh'
echo "done with $DBSET restore from production"

# This is sending you a message letting you know that (in theory) the
# restore finished but the whole process is missing any serious error
# checking and any positive validation that the work really got done.

mailx -s "$MSG" $EMAIL </prod1/yesin

 

[tamhas]

Apparently I'm a glutton for punishment tonight

Apparently...