Who needs it?
Have you ever wundered how your SQL Server(s) were doing
down on the 13th floor while your up on the 15th floor
troubleshooting a workstation with no Enterprise Manager
available on this side of the elevator?
Have you ever had to reinstall the OS on the PC you use to dial
in from home and not have the SQL Server CD available, yet needed
to check the system from home once the OS was reinstalled?
Have you ever needed to run a DBCC check_ident while you were
in a long and important meeting with no time to get back to your
workstation or the computer room without dropping out of the meeting?
Did one of these questions cause you to recall another situation
where you we not able to get to an Enterprise Manager, but you
desperately needed access to your SQL Servers?
If so, here is a solution. Virtually every PC has a browser. If you
set up a utility that will give you the ability to check the status
of your SQL servers and add, modify or run tasks in a documented SQL Server
network from a browser then you will be better able to administer your
system from anywhere at anytime as long as you have a browser available.
I use the admin subsystem utility in a distributed environment. While
you could make full use of the tool in a one database environment, the prevalence
of distributed SQL Server environments leads me to the conclusion that
the materials offered here will be most relevant if presented in the context of
the distributed environment. It should be relatively easy for you to determine which
processes and concepts to use in a single SQL Server environment.
Everything I will show you is in use in a hybrid (OLTP/Data Warehouse) system
with a remote hot site using SQL 6.5 SP4, IIS 4.0, and Windows NT 4.0 SP3. I
have made an effort to make sure everything works with the latest Netscape
and Microsoft browsers, but the reality is that this utility will provide too much
power to risk exposing it to the internet. This means you can build your subsystem to work
with only one browser product if you only use one in your enterprise. This is an
important consideration for you because once you start using the architecture you
build with the admin subsystem you will want to extend the functionality as
appropriate to your system.
The first step will be to establish communication from the browser population you
wish to include to the SQL Server where your scheduled tasks live. This will enable
you to check the tasks from any of these browsers. Take a look
at a small demonstration of the Active Tasks Status Inquiry. The buttons on the main menu
have been abbreviated in the demo so that you can see a couple of possible scenarios. The opening
scenario (the "Normal" button) is what you could expect to see when the administration tasks and
the servers in the network are running normally. A second scenario (the "Broken" button) depicts a network with some problems. This should
give you a good idea of how easy it is to keep an eye on the servers with this tool.
(The demo represents screen shots of a system. No live system is connected to this site.)
If you want this for your system, follow the instructions.
Once the first step posted and there is some feedback that people want more, you can expect to
see details on documenting the SQL Server network in an admin database, scheduling SQL Server tasks
from the browser, and complete source for scripts used to administer the SQL Server network.
I guess that's the catch. You gotta let me know if you want more.