Abstract: A method of generating a test database from a deployed database by “sanitizing”, or removing sensitive data, is employed for recreating problem scenarios from a customer site, verifying compatibility of customer data with database version updates, and for performance testing using actual, rather than generated, database structures. In database management operations, in can be beneficial to use data generated from actual operational scenarios rather than artificially generated data created from a test pattern. Data generated from actual operation, such has at a customer site, assures compatibility with the relation patterns and record volumes employed by the customer (user). However, databases often contain sensitive information that would be inappropriate, illegal, or vulnerable in a testing environment. Accordingly, the generated test database overwrites sensitive data values with benign, or generic values while preserving the structure and relations of the data stored.

Abstract: A SAN management application stores a password file in a secure repository inside a database to which the stored passwords provide access. A separate database account (i.e. login) is created to afford access to the password repository. The password repository, typically a database table or file, is stored in a secure area accessible only by the specialized password account. A separate password, or access token, is employed for access to the password repository account. Executable entities, such as processes of the management application, are encoded with the password, or access token, to the password repository account. From the password account, the password repository provides availability to the stored passwords for specific privileged access by designated processes. In this manner, a dual level authorization is provided to privileged database operations, and corresponding logic embedded in particular processes authorized to traverse both levels.

Abstract: A SAN management application maintains configuration information in a near real-time (RT) manner for timely and accurate responses to queries. A database manager responsive to the management application aggregates information concerning both current and historical configurations by combining current and historical information sets as a common (DB) database portal responsive to an individual query for configuration data from both current and historical data. The common portal avoids redundant and duplicative entries between the current and historical information sets, and is responsive to the management application for maintaining each change on only one of the current and historical information sets. Configuration changes add, update and move data items between the current and historical information sets, but need not store a configuration change in both the current and history information sets.

Abstract: Upgrading an original repository of data is disclosed. A repository is defined by a set of schema structures and data contained therein. A copy of the original repository is exported. The set of schema structures of the original repository is modified to create a set of schema structures of the upgraded repository. Schema structures that are not present after the upgrade are deleted after data migration is completed. Data is migrated to the set of schema structures of the upgraded repository. Data includes existing data from the original repository and seed data for the upgraded repository. Existing data is copied into the appropriate schema structures of the upgraded repository. Seed data is inserted into new schema structures of the upgraded repository. The set of schema structures of the upgraded repository are validated against a standard set of schema structures corresponding to a properly upgraded standard repository to detect any errors.

Abstract: A database environment includes a staging database and master database. Among other functions, the staging database provides a location to store data prior to be copied over the master database. Each time the database environment is modified (e.g., a developer specifies a different configuration associated with the staging database and/or the master database), a database administrator initiates execution of an auto-repository process to automatically generate a corresponding new set of routines enabling management of the database environment. Accordingly, each time there are changes to (one or more schemas associated with) the database environment, there is no need for a programmer to manually modify the corresponding management routines based on the changes. Instead, the auto-repository process automatically generates the corresponding set of custom routines to enable management of the database environment.

Abstract: Generating a repository template of a repository of data for a storage area network (SAN) management tool is disclosed. The repository will hold data describing SAN elements and configurations, and will be stored on a host. A configuration file is updated to include current configuration data for the repository, and includes specifications for a set of new schemas that define structures within the repository. A set of new schemas is created from those specifications. Seed data that defines initial information for the repository is copied to the host. New schemas are initialized with the seed data. A repository template is generated from the created set of new schemas and the seed data, from which one or more repositories may be created to hold SAN data.

Abstract: A system receives a dataset for storing in a staging database. The dataset contains network management data collected from a managed resource. The system stores the dataset in the staging database, and maintains a changeset identifying changes made to the staging database during the step of storing the dataset. The system synchronizes the staging database and the production database with each other using the changeset.

Abstract: A system detects an event suggesting a data discrepancy between a staging database and a production database that maintain network management data within a network management system. The staging database is logically separate from the production database. The system prevents modification to the production database, and replaces data in the staging database with data from the production database. The system then allows modification to the production database.

Abstract: A method of generating a test database from a deployed database by “sanitizing”, or removing sensitive data, is employed for recreating problem scenarios from a customer site, verifying compatibility of customer data with database version updates, and for performance testing using actual, rather than generated, database structures. In database management operations, in can be beneficial to use data generated from actual operational scenarios rather than artificially generated data created from a test pattern. Data generated from actual operation, such has at a customer site, assures compatibility with the relation patterns and record volumes employed by the customer (user). However, databases often contain sensitive information that would be inappropriate, illegal, or vulnerable in a testing environment. Accordingly, the generated test database overwrites sensitive data values with benign, or generic values while preserving the structure and relations of the data stored.

Abstract: Techniques herein involve anticipating the application of a command to modify objects having associated object data stored in a relational database. Prior to receipt of an object modification command that causes a modification to a respective object and/or an object hierarchy, a computer process generates a set of operational instructions to carry out the object modification command. Generally, the computer process analyzes a structure for storing object data in a relational database to identify information in the relational database that will be impacted as a result of executing a corresponding object modification command. Based on analysis of the structure, the computer process generates the set of operational instructions. The execution of the set of operational instructions to carry out the command causes the respective object and/or object hierarchy to be modified as well as causes a corresponding modification to contents of a relational database storing respective object data.

Abstract: A system receives a dataset for storing in a staging database. The dataset contains network management data collected from a managed resource. The system disengages a connection between the staging database and a production database, and stores the dataset in the staging database. The system then re-engages the connection between the staging database and the production database.

Abstract: A computer process initiates a pre-analysis of managed objects and corresponding structures for storing object data in a relational database. The pre-analysis yields a set of operational instructions (e.g., a “stored” database procedure) that can be applied at run time to more efficiently initiate a modification to objects and corresponding object data stored in a relational database. After execution of a stored procedure to modify contents of an object and respective contents in a relational database, a synchronizer utilizes an identifier to access a log that stores changes associated with a managed object to which the stored procedure was applied. Based on contents of the log, the synchronizer identifies changes to one or more managed objects and identifies corresponding processes that rely on use of the affected managed objects. The synchronizer then notifies corresponding processes utilizing the affected managed objects of the changes to the relational database and/or managed objects.