How much of perl knowledge is required ?
Max, April 03, 2003 - 4:38 pm UTC
Tom,
A lot of experienced DBAs recommend learning perl to make life easy in the unix world for administration; whereas some recommend any korn/bourne shell scripting.
What is your advise/recommendation for budding DBAs like me who dont know either of the above ???
April 03, 2003 - 9:15 pm UTC
PLSQL, RMAN...
then, you can script on a mainframe, unix, or windoze without concern for the OS.
Me, I can count the OS scripts I use on one hand, with just some of my fingers... dbms_job -- better then cron. sqlplus -- my execution environment. OS -- just doesn't really matter.
FUP - How much of perl knowledge is required
Jim, April 03, 2003 - 11:14 pm UTC
Max,
I was using Perl back in 1996, then I went contracting
I worked at ALOT of sites but it wasn't until 7 years
later that I had to use it again .
During those 7 years I wrote many many shell scripts
so shell scripting was more important to me.
Personally I love Perl, glad to be working with it again
but there was no requirement for me to use for a long time.
My advice would be learn some shell scripting,
by all means learn Perl too but not everywhere
will have Perl but I have never been to a Unix site yet
that didn't have shell scripts..
Regards
Jim
Thanks !
Max, April 04, 2003 - 9:57 am UTC
Tom & Jim : Thanks for your answer. Tom, I already know PLSQL, RMAN etc. I was asking about the scripting side -- sorry I was not clear.
Jim, thanks for your answer. And with shell scripting, does it matter what shell ? What shell is used more w.r.t. database administration ?
April 04, 2003 - 11:31 am UTC
but, if you do your "scripting" in those languages -- you don't even need a shell script -- that was my point
scripting using plsql vs shell
Max, April 04, 2003 - 12:11 pm UTC
Tom: I too am a strong follower of PLSQL and I agree that most of the scripting tasks can be done using PLSQL. But what about those places where we try to get a job ? Those folks are still demanding that the dba *must* have working knowledge of shell scripting.
And personally I have not worked on unix, so I cant tell where plsql would fall short and then one has to take support of shell/perl scripting.
shell script if a must if you are in linux or unix
A reader, April 04, 2003 - 2:57 pm UTC
it's a must, period
Perl is cool as well, in fact quite a few scripts that comes with Solaris 9 are already in Perl, also Oracle IAS comes with many Perl scripts.
You dont need to be expert in shell script or Perl, they are pretty simple if all you want is monitoring, administration, pattern matching etc Shell can start to get complicated when you want to deal with processes, sub shells...
I have been several shops and many of them bases their ETL Process on KSH scripts, PL/SQL and SQL scripts (Have seen Perl as well but not as popular), the advantage of Perl is it is more like programming language than scripting language, it integrates well with C libraries (you call C functions in Perl, not sure about Shell scripts), it's more flexible and powerful and seems that quite a few software providers noticed that.
If I am correct I think OEM used to use TCL (another scripting language) but there are some Perl now as well!
not sure if you are development DBA
A reader, April 04, 2003 - 3:02 pm UTC
Hi again
I am stating my view from a production DBA view, we code shell scripts and Perl scripts now and then, quite often. If you are developer or development DBA then I am not sure how useful can shell scripts or Perl useful to you.
PL/SQL is fine but not to deal with OS, it is for what it is designed for, inside database. What if the database is down? In practice I have seen more an instance failure than a server boom boom (dies!)
April 04, 2003 - 6:38 pm UTC
yes, but if the database is down -- what work are you going to do beyond "startup"?
which shell ?
A reader, April 04, 2003 - 3:51 pm UTC
When you all talk about shell scripting, which shell are you referring to? I dont know how much they differ from each other, but I know they are different.
PL/SQL ,RMAN
Tarry, April 05, 2003 - 5:32 am UTC
I really agree 100% with tom there......
Rman : You'd want to look into why you would want to use rman as against the regular os scripts. You'd see that rman outweighs things in tons..save space,so much of automation is possible, I mean I see people posting on forums as to how to automate and delete arch log files thru os scripts while rman with a simple command will do the job for you, it checks during backups for fractures, I mean you can go on and on..
dbms_job? Well it's one of the many packages in the pl/sql supplied packages which is over 2000 pages book having practically everything you'd want to do with pl/sql.
Perl
Beth, October 15, 2003 - 1:39 pm UTC
It was not useful to me because it did not address my initial question: Do the database connections, via a Oracle::DBD, by-pass the tnsnames.ora and why does it happen that way?
October 15, 2003 - 6:42 pm UTC
hmmm I do not see any questions from "beth" before this?
if it is using "user" "password" "connect string" -- no, it is not.
perl just uses oci, oci uses net8, net8 will do the same thing whether perl invokes it or sqlplus is the application using it.
There is a need for shell or perl scripts for DBA
Jeff, October 16, 2003 - 12:57 pm UTC
Tom, in 'Expert One-on-One', you give a clear example of why you would want to use the shell during export/import. In order to compress/limit file size of export and to place the export in a safe holding area you would need to use the shell.
I agree that a DBA must have a command over PL/SQL and RMAN, but a little help from the shell can give you more options when managing your DB environment. If you follow a layered approach to backup and recovery than the shell and or perl can be a great help.
Shell scripts can also help the DBA to understand what is happening at the OS level and why. My background as a UNIX SA, which has entailed years of writing shell scripts has made me a much better DBA.
October 16, 2003 - 5:28 pm UTC
as i said tho
... Me, I can count the OS scripts I use on one hand, ....
one hand. tiny, few, far between, hardly at all, in the future (soon) ZERO, zippo, none.
trace file move
jas, May 02, 2006 - 3:48 pm UTC
Tom,
Can you please suggest some site/link to get a script to move trace file in some other folde from udump?
I am not good scriptor.
Thanks!
May 02, 2006 - 4:04 pm UTC
gee, guess it would depend on your scripting language?
I use csh, how about you :)
scripts
jas, May 02, 2006 - 6:05 pm UTC
:D
But help me to find script to backup trace files
May 03, 2006 - 1:44 am UTC
*write it*, scripting is not excessively difficult.
I don't have one to backup trace files specifically.
That and you didn't even get the gentle point about scripting language. You are probably on windows (a guess), therefore almost anything I write would be useless for you.
Ok, here is one in sh
#!/bin/sh
mv $1 $2
you pass it the name of the file to move and the directory to move it to. Yes, that was tongue in cheek, but really - this is not "write my script for me.com"
perl
jas, May 03, 2006 - 12:44 pm UTC
You have excellent sense of humour :)
I am on linux ;)
May 03, 2006 - 1:29 pm UTC
then I am done - I gave you the script - I don't do perl myself, I use sh, csh and ksh.
A reader, December 22, 2008 - 5:26 am UTC
Hi Tom
I have a perl script which does the following
It first counts the rows of a table(say realtor this one has over million records) and dumps that value into another table (say abc)
Then it starts doing an insert into a table(say test)(direct insert from this table realtor)
Can you please suggest me a way how I can do these things simultaneously ? that is while the insertion is going on I want the counting to happen too using perl?
Any help will be greatly Appreciated
Thanks
December 29, 2008 - 2:55 pm UTC
why do you count and then insert?
you do realize the count you get and the number of rows inserted might be different right?
why not do this:
create function foo return number
as
l_cnt number;
begin
insert into t select * from t2;
l_cnt := sql%rowcount;
return l_cnt;
end;
and just call that from perl.
forget that count(*) even exists, never run a query to count things and your life will improve an order of magnitude or more.
A reader, December 30, 2008 - 12:33 am UTC
Thanks Tom
I am the same user from above ... We require the count and the direct insertion to happen at the same time as the count is for validation purpose and the insertion is for migrating the data from one table to another.And this count is to be stored in a table/view to present the same to the client.I will try the method you have mentioned above ... but is there an alternate way to do this in less amount of time using perl/oracle dbi/dbd?
January 05, 2009 - 8:39 am UTC
... but is there an alternate way to do this in
less amount of time using perl/oracle dbi/dbd? ...
do "what" in less time? Not sure what you mean.