Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: PERL?
One BIG advantage of Perl is DBI. Via shell you can't use bind variables
which sometimes come in handy. An admin dweeb here developed a
monitoring shell script that executed 5500 queries an hour each using
literals instead of bind variables resulting in shared pool
fragmentation and server errors. When the same monitoring was rewritten
in Python the load on the server was dramatically reduced. (It could
have been done in Perl with the same result.) The usage of literals
could have been avoided with PL/SQL but there was also a need for
significant file reads, file writes and email so using shell and PL/SQL
was cumbersome at best. (Besides, the admin dweeb didn't know PL/SQL.)
Another plus is that your oft used routines can be portable between
Windoze and *nix.
I guess the point is this: Many times you need greater programming power than afforded by shell scripting. If you can easily and productively perform everything that you can do in shell scripting with a complete programming language like Perl or Python then you're one step ahead of the game. Otherwise you may be lamenting limitations. So the remaining challenge is merely learning a programming language that works for you.
Steve Orr
Bozeman, Montana
-----Original Message-----
Stephen.Lee_at_DTAG.Com
Sent: Monday, December 08, 2003 9:14 AM
To: Multiple recipients of list ORACLE-L
The difference that has affected me the most in writing utility scripts is that PERL can talk to the database like using a telephone. Ksh must talk like using a walkie-talkie; that is, each side of the conversation must talk then release the push-to-talk (PTT) button before the other side can talk. Using a small amount of cleverness (which is good, because that's about how much I have) in ksh, you can program around most of the communication limitations. For example, to deal with sqlplus getting "stuck" for one reason or the other, you can run the subsection of the script in the background (as a ksh job). Then you check on the job later in the script. If the job is still there longer than it should be, the script can kill the job. THEN, for good measure, look for sqlplus (and possible another ksh that got forked by the script) with parent process ID (PPID) of me and kill them. This is similar to the other side failing to release the PTT button. Unlike PERL, which can maybe yell into to telephone to wake the other side up, ksh must launch an artillery shell onto the other guy which, in a rather violent manner, will cause him to release the PTT button (well ... actually .. the PTT switch kind of got blown up too). Then, depending on the situation, retry the sqlplus or conclude that something is wrong.
That being said, ksh is so easy to use and so handy, that I still use it for automating database management and monitoring. I'm sure a big part of that is because I learned shell, sed, awk, etc. programming before perl was standard equipment on Unix boxes. I suppose if you are starting from the beginning, then the way to go would be perl. But you can still do a heck of a lot with ksh (the REAL ksh; not the POS public domain ksh that tends to show up with linux).
For an excellent book on getting started with this, go to Amazon and search on Mark G. Sobell (or just Sobell).
Here's a tinyurl link to what I think is still must-have book. Even though a lot of it is outdated, the sections on getting around in Unix and shell scripting are still entirely relevant. http://tinyurl.com/y8x6 (Note that the used book sellers are just about giving away the book)
There is also a BSD version of the above book.
And you want to get O'Reilly's book on Sed and Awk.
Those should get you going down the wonderful world of shell scripting .. which is the ORIGINAL, and still great, Rapid Application Development.
-----Original Message-----
I've read a lot about PERL on this list. And, I am wondering what can you do with PERL that you cannot do with SQL*Plus, PL/SQL or Unix shell scripts?
Any information will be greatly appreciated.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: <Stephen.Lee_at_DTAG.Com
INET: Stephen.Lee_at_DTAG.Com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services ---------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Orr, Steve
INET: sorr_at_rightnow.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services ---------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Mon Dec 08 2003 - 14:04:28 CST