Configuration Database Management with Transaction Logs

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current network management software lacks comprehensive object management processes, leading to inefficient synchronization and persistence support, resulting in significant programming overhead and potential data loss during network failures.

Innovation Solution

A configuration database management system that uses a database manager and transaction log file to maintain managed objects, with object reference keys and storage location pointers, enabling efficient transaction support and persistence through logical dependencies and rollback mechanisms.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If typical network management software uses map or keyword systems to manage objects, then objects can be identified and processed, but significant programming and processing overhead is created

Engineering Contradiction:

ImproveObject management efficiencyVSAvoidProgramming overhead

Core Design Contradiction:

Ease of operationVSDevice complexity

Solution Approach 1:

The patent segments object management into distinct components: object identifiers (keys) separate from object data, storage location pointers separate from object content, and transaction logs separate from configuration data. This segmentation eliminates the need for complex map lookups by providing direct access paths through pointers and keys, reducing programming overhead while maintaining object identification capability

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent introduces transaction log files as an intermediary between configuration changes and actual object storage. The transaction log captures all modifications before they are committed to the configuration database, providing a buffer that simplifies error handling and rollback operations without requiring complex synchronization code, thus reducing programming overhead

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If network failure recovery is performed without efficient mechanisms, then network can be restored, but significant amounts of transmitted data are lost

Engineering Contradiction:

ImproveData integrity during failureVSAvoidTransmitted data loss

Core Design Contradiction:

ReliabilityVSLoss of information

Solution Approach 1:

The patent performs preliminary actions by continuously logging all configuration transactions to transaction log files before they are committed to the configuration database. This preliminary logging ensures that if a failure occurs during transmission or processing, the transaction can be recovered by replaying the log entries, preventing data loss without requiring complex recovery mechanisms

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The transaction log file serves as a cushion against data loss by capturing all configuration changes in a protected, write-ahead format. This cushion allows the system to withstand failures during configuration updates by rolling back to the last committed state using the transaction log, thereby protecting transmitted data integrity without requiring additional protective measures

Inventive Principle:

Principle #11Beforehand cushioning (Prior cushioning)

3Reliability

If configuration data is not synchronized efficiently across network elements, then data consistency can be maintained, but synchronization time and network overhead increase

Engineering Contradiction:

ImproveConfiguration data consistencyVSAvoidSynchronization time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The patent extracts only the necessary configuration data and transaction information from the configuration database for synchronization purposes. Rather than synchronizing entire database structures or object graphs, the system extracts specific configuration parameters and their change status, transmitting only what is necessary to maintain consistency across network elements, thereby reducing synchronization time while maintaining data consistency

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The patent implements local quality by allowing each network element to maintain its own configuration database with locally optimized data structures. Each element synchronizes only the specific configuration parameters relevant to its function rather than maintaining identical copies of all configuration data, reducing network overhead and synchronization time while ensuring local data consistency through targeted updates

Inventive Principle:

Principle #3Local quality

Data Source

PatentUS7991849B1System for managing configuration memory with transaction and redundancy support in an optical network element

Publication Date: 2011.08.02 CIENA CORP

AI summary

A system for managing and updating a configuration database for a network element is described. The network element includes several managed objects. The managed objects represent logical representations that can be configured and modified through transactions executed by the network management software. The configuration management system includes a database manager that maintains a database file and a transaction log file. Each managed object includes an object reference key and a storage location pointer. Logical dependencies among objects are maintained through the linking of storage location pointers in the objects. Actions that modify an object are stored in the database file and the transaction log file. The present state of an object is stored by the database management system. In the event of an abort condition, the most recent configuration state of the network element is restored by re-applying the transactions stored in the transaction log file, and resolving the pointer links contained in the affected managed objects.