1 / 29

Federated MDBs with Multiple SQL Instances

Federated MDBs with Multiple SQL Instances. Last Revision Date: September 6, 2006. Glossary. The following terms and abbreviations are used in this presentation: “HA” = Highly Available “UAPM” – Unicenter Asset Management Portfolio “USD” = Unicenter Service Desk

mignon
Download Presentation

Federated MDBs with Multiple SQL Instances

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Federated MDBs with Multiple SQL Instances Last Revision Date: September 6, 2006

  2. Glossary • The following terms and abbreviations are used in this presentation: • “HA” = Highly Available • “UAPM” – Unicenter Asset Management Portfolio • “USD” = Unicenter Service Desk • “DSM” – Unicenter Desktop Server Management • “eIAM” = CA eTrust Embedded Identity and Access Management • “MSCS” = Microsoft Cluster Server • “NSM” = Unicenter Network System Management

  3. Overview

  4. Objectives • The objective of this document is not to discuss MDB Federation or what products should share MDB. For a detailed discussion of MDB federation and deployment choices consult the MDB Federation presentation instead • The main objective of this presentation is to review the implications of installing multiple SQL MDBs on a single server having multiple SQL instances. Additional information is provided regarding the install of multiple SQL MDBs in a Microsoft cluster environment • These discussions assume that you have already reviewed the MDB Federation presentation and wish to pursue federation on the same server or same cluster

  5. Why use multiple SQL instances? • Reduce cost of ownership • If correctly planned, the normal mode of operation in a Microsoft Cluster environment can include active SQL instances on different nodes of the cluster. This provides federation without overloading single cluster node. • In the event of a failover both SQL instances can potentially be active on the same node. • This would not be classified as “normal” mode of operation

  6. Default SQL Instance • Some products do not support named SQL instances. DSM is one of these, but it is targeted to support named instances soon. • Although DSM will install correctly using named SQL instances, there are some issues with named SQL instances • Therefore, if DSM is being installed in an environment using multiple SQL instances, one of the SQL instances should be the default instance.

  7. Multiple MDBs – one Product • Installing multiple MDBs for the same product on the same server can cause the product to malfunction and, in some cases, the install process will prevent it from being installed. • NSM install process prevents multiple MDBs from being created on different SQL instances running on the same server. • Several NSM components caches repository (MDB) details. If MDB location is changed password and MDB details must be updated for all of these components

  8. NSM and Multiple MDBs • NSM MDB has been locked down with named SQL instance (SQLINSTA) • Install processes attempts to create another NSM MDB on a default instance • Install process for subsequent NSM MDBs will prevent override of the database server or SQL instance details

  9. NSM and Multiple MDBs This shows multiple NSM MDBs cannot be created on the same server

  10. SQL Instances This shows default and named SQL instances – each with an MDB

  11. Multiple SQL Instances This shows cluster setup with default and named SQL instances each having an MDB spread across different products

  12. Install Summary for Cluster and Non-cluster Configurations

  13. SQL Named Instance SQLINSTA NSM SQL Default Instance DSM USD eIAM – Ingres Instance NSM Worldview Enterprise Mgt WV Provider Multiple MDB instances Single Server - Multiple MDB Instances This shows non-cluster setup with multiple SQL MDBs

  14. Single Server: USD – Default Instance • Here USD MDB is installed on a default SQL instance while NSM MDB exists on the named SQL instance • In addition, eIAM is selected (this will install Ingres ET instance, as well)

  15. Single Server: NSM – Named Instance • Here NSM MDB is created on named SQL instance while USD MDB already exists in the default SQL instance

  16. Single Server: SQL Instances This shows two MDBs on different SQL instances installed on the same server

  17. Single Server: SQL Instances Services

  18. Cluster Setup • This shows two SQL instances - default and named. Each instance will have MDB based on the MDB deployment choices discussed in the Federation presentation

  19. Cluster Setup: DSM MDB Install • This shows DSM MDB installed on the default SQL Instance which it shares with USD and UAPM. NSM MDB will be installed on a named instance

  20. Cluster Server: SQL Setup • This shows two SQL instances, each with an MDB in a Microsoft Cluster setup

  21. Gotchas

  22. Considerations • There should not be any special considerations for installing multiple MDBs on the same server using different SQL instances or for installing in a Microsoft Cluster environment using multiple SQL instances. • The considerations listed in this section are not specific to multiple MDBs on the same cluster or server

  23. USD and DSM Install order • If USD and DSM will share an MDB, install DSM first. Otherwise, you may experience 1603 error (The setup here was USD 11.2 and DSM 11.1a without C1 fix)

  24. DSM Install MDB • DSM may identify existence of previous MDB and generate a dialog box which may be irrelevant for SQL MDB

  25. System Path • Unicenter NSM install validates the system path length, computing the length of system path entry based on NSM products selected. If the computed length exceeds 1024 bytes the install will not continue • If multiple products are installed, it is likely the system path length will be exceeded

  26. System Path Prior to Install This shows system path prior to installing any NSM components. The path entries listed above include pre-installed DSM Agent + Software delivery plug-in, eTrust Antivirus option, and USD eIAM option

  27. Path Length Exceeded

  28. Circumvention • To circumvent this potential problem, change the location of CA Common Services from “\Program Files\CA\SharedComponents” to “\CA\SharedComponents” • Alternatively, shorten path length by changing existing entries to short name (8dot3 format). For example: • C:\Program Files\CA\eTrust Directory\dxserver\bin to • C:\Progra~1\CA\eTrust~2\dxserver\bin • User dir /X to option convert to 8dot3 format • Remove duplicate entries

  29. Directory Name Shortened Changed CA Common Services location from \Program Files\CA\SharedComponents to \CA\SharedComponents

More Related