|
|
|
|
|
DBArtisan 5.03 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 The Script Execution Facility is a new feature in DBArtisan 5.03. This is a first generation feature that does a pretty good job. However, there are several improvements that need to be made to make it very useful. The Script Execution Facility allows you to execute a script against multiple servers in batch. If you had a particular script that needed to be run against 40 or 50 servers, you would spend several hours connecting to each server and running the script. The Script Execution Facility reduces this to minutes. The first tab is where you add the script that you want to run. You will notice one thing missing here. There is no open button! This means you have to either type the entire script from scratch into this window or save a script to a file, open it in Notepad, copy it to the clipboard, and paste it into the script window. Very kludgy and cumbersome. A simple open button would have been most welcome. The other thing that causes an irritation with this feature is that it is a modal dialog. While the Script Execution Facility is open, you can not access anything else in DBArtisan, so make sure you already have the script you want to execute copied to the clipboard before bringing up this dialog.
The target tab is what gives this feature its power. You can select multiple datasources to run the script against. The Script Execution Facility will connect to each server that you specify, execute the script, and continue on to the next datasource. You will notice that there is a box at the bottom for a database name. This means you can execute the script against only one database and it has to be the same database across all datasources. This is another limitation that you will need to account for. I should be able to select the database to execute against on a server by server basis. It has the additional limitation that it can only execute against a single database per server. Unless you code that functionality into the script you are executing, you will have to run this once per database that you want to run the script against. The other thing that happens is that connections are left open. If it has to open a connection to a server to run a script, it should close that connection when it is done. Because it doesn't close the connections, you have to clean up after it. It can also introduce some barriers if you have not configured the options correctly. The option settings will be discussed in detail at the end of this review. The output tab allows you to specify how you want the output from the tasks displayed. The notify tab allows you to send a notification when the job completes. Even with the limitations inherent in the first generation of this feature, the Script Execution Facility alone can save you enough time in a large environment to justify the cost of DBArtisan. One of my clients has several hundred servers around the world. We have a set of administrative procedures on each server. Every once in a while, we will add a procedure, modify one, add jobs, or change job schedules. Without the Script Execution Facility, they had one DBA that would spend several hours connecting to each server and executing these scripts. In some cases, this could consume an entire day. We added DBArtisan 5.03 into the environment and reduced this time to less than 5 minutes to perform the same tasks.
DBArtisan 5.03 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.
