Re: Has anyone used the QuestSqlPlus Toad tool from Toadsoft?

jim wrote:
>
> "Sean M" <smckeownNO_at_BACKSIESadelphia.net> wrote in message
>
> The TOAD UNIX job scheduler allows you to manage all your job files in one
> window. It lets you view and enter parameter values for all jobs, it lets
> you schedule jobs with an intuitive & programmable interface to the crontab
> parameters (which are anything but intuitive), it lets you set up and manage
> multiple servers at the same time, it lets you set up scheduling & input
> parameters to your job files then copy these out to multiple servers. After
> this step is complete, you can deploy your jobs to multiple servers (ftp
> behind the scenes). The scripts will be sent out to each server, the
> crontab file will be created on the client and deployed to each server. All
> jobs are executed via a manager script file which automatically spawns off
> log files for each job scheduled. Then, on the client, you can check the
> status of cron, you can view the crontab files, you can view the log files
> on each server and so forth. Even if you are a cron wizard, you can add
> meaningful (plain English) scheduling dates to the interface for your own or
> others use. For instance, "every Tuesday at 2:45pm". Then this scheduling
> info remains and can be used to schedule jobs for the various servers you've
> told it to. The "deploy" is a one-step process whereby it updates the
> manager script file, creates the crontab file, ftp's everything to the
> servers and starts cron going on the new information.

OK, thanks for the details. Unfortunately, I still don't think that helps me any. Like I said, I don't find the 10-second process of telnet/ssh, msu, and crontab -e to be so difficult that I need a GUI to help me with it. Besides, if TOAD is using FTP under the sheets, it is worthless in a highly secure production environment where FTP is forbidden. Heck, it's worthless even in our less secure environments where we still don't allow direct access (telnet/ssh/ftp/whatever) as oracle (you always have to msu). And (personal preference here) I would be extremely skeptical of using a 3rd-party GUI to do any sort of mass deployement of crontab changes on production systems. Adding meaningful, plain English comments to crontab entries? Well, that's what we use # for now. I know it sounds like I'm picking on you and TOAD, but I'm just pointing out that the basic tools like telnet/ssh/vi/sqlplus still have their place in the modern GUI world. I'm all for GUI's for certain tasks, but anyone who can't also get the job done with telnet and vi and sqlplus have no business being a dba in a large production environment.  

> We ship with around 60 of the most common jobs (export table, database
> shutdown, and so on ad nauseam). In addition you can add your own to the
> dictionary.

Which begs the question - who is using your canned scripts for common jobs in a production environment? People that probably ought to have more experience - I assure you that any DBA who couldn't shutdown a database without assitance from TOAD wouldn't be working for me for very long. Does that mean you shouldn't include them in your product? No, by all means, put them in there. I just take exception to the insinuation that you're somehow going to replace SQL*Plus with a GUI like TOAD.

> In your situation, if everything is always ad hoc, then this doesn't do
> anything for you.

I never said everything I do is ad hoc. Some is scripted, some isn't.

> But it does allow the complete Unix novice the ability to
> perform these tasks.

And that's exactly my concern. I believe that complete Unix novices have absolutely no business mucking around with crontab entries for oracle or root on production systems. Personal preference, and maybe a dinosaur's mentality, but it's served me well so far.  

> We do support AutoTrace.

Your website (http://www.toadsoft.com/Enhancements.htm) says that the new Beta version of TOAD only partially supports autotrace:

SET AUTOTRACE (statistics only)

I read that to mean you don't support the traceonly and explain options.

> I never intended to support Sql*Plus anything; we're a gui tool and not a
> script engine.

So why do you come here and insist that your product is going to do away with SQL*Plus? Why criticize SQL*Plus and those who use it so vehemently? It is what it is: a great command line tool.

Regards,
Sean Received on Sat Aug 31 2002 - 20:59:32 CDT