 |
SQL Enterprise Manager--How It Should Be Done
The degree of integration between Microsoft Corp.'s latest beta version of SQL Enterprise Manager (SEM), SQL Server, Windows NT and Microsoft Management Console (MMC) is quite high. SEM's integration should serve as an inspiration to database tool vendors, who tend to use an unsophisticated, lowest-common-denominator approach to managing databases. These vendors need to further insulate their tools' central console
s from the specifics of each database being managed. They also should offer browser-based interfaces and work directly through database administrative APIs, rather than indirectly via a database's command-line query utility.
The SEM bundled with SQL Server 7 beta is completely revamped, running as an MMC snap-in. MMC's point-and-click user interface is similar to Windows Explorer, offering users some familiarity. The snap-in (Oracle calls it a cartridge) architecture is certainly more complex, but RDBMS tools vendors should consider its advantages.
MMC's three-tier distributed architecture, with DCOM (Distributed Component Object Model) and ActiveX APIs, lends itself to Web-based programs. They can use the OLE interfaces for administration activities to provide browser-based RDBMS administration and manipulation. The SQL Server 7 beta version comes with Web pages that mirror many of SEM's capabilities.
With SEM, you can define a multiserver domain, naming one server as the master server to communicat
e and distribute jobs, alerts and messages to target servers. You can manage the enterprise's SQL Server databases from a central (master) SEM instance, as well as monitor SQL Server's performance across the network. From a SEM master server, you can perform cross-server transactions; configure users, groups and security; replicate content; alter schemas; set up alert thresholds and create multistep database maintenance jobs. You can schedule these jobs, monitor and manage the job flow and store job-completion status information at a central location.
Granted, the programming interfaces for administering database products from IBM Corp., Informix, Oracle Corp. and Sybase Corp. are not as complex as Microsoft's. But vendors can subsume these differences by providing database-specific insulating layers of software for translating the administrative APIs into a common, database-neutral API that the management tool interfaces with. An insulating layer would use the administrative API of a particular RDBMS, whi
le exposing an RDBMS-neutral interface to the central console. Adding a Java interface to the RDBMS-neutral API would let DBAs administer their databases via a Web browser. In contrast, launching a query tool and issuing dynamic commands and SQL to the database through the query tool, as Tivoli's Distributed Monitoring component does, is the wrong approach.
|
 |