Database Migration over Network
Active In SP
Joined: Sep 2010
24-12-2010, 12:38 PM
Mohd. Farhan Rawani
VINAY Database Migration Over Network report final.docx (Size: 1.3 MB / Downloads: 176)
Title: Database Migration over Network
This project and implimentation aims to bring up the idea of automation of transfer of data structure (table) designs as well as data (records) from one DBMS to another (possibly different type of) DBMS across the network. The system has a source side (client) and destination side (server) parts. At the source side, the user selects a given RDBMS (say Oracle, MS SQL server, DB2, Sybase etc.) and interrogates to get a list of tables present in the system. He chooses a table, selects the columns of the table to migrate and sets up a filter condition for the records to pick. The user also specifies the destination RDBMS system (need not be the same type as the source) The definition of the table selected and its records are read by the application, converted into socket object and transmitted to the destination side application (server) using the network. The destination side application receives the Object, parses them and creates the required tables and records in the destination RDBMS
The project and implimentation becomes very useful for an administrator who wishes to switch from one DBMS system to another. The entire data conversion becomes reliable, fast and efficient. These findings proved that Migration of database from a source machine to a destination machine is a very helpful application.
It may be necessary to move from one database vendor to another, or to upgrade the version of database software being used. The latter case is less likely to require a physical data migration, but this can happen with major upgrades. In these cases a physical transformation process may be required since the underlying data format can change significantly. This may or may not affect behavior in the applications layer, depending largely on whether the data manipulation language or protocol has changed - but modern applications are written to be agnostic to the database technology so that a change from Oracle to My SQL, DB2 or SQL Server should only require a testing cycle to be confident that both functional and non-functional performance has not been adversely affected. A method of migrating a database from a first server to a second server while continuing to provide transaction service, the method comprising the steps of: providing transaction service on the first server; establishing a database copy on the second server; logging at least one transaction from the first server to create a transaction log; executing the at least one logged transaction on the second server; repeating the steps of logging at least one transaction and executing the at least one logged transaction on the second server until a set point is met; queuing at least one transaction request; executing the at least one queued transaction request on the second server; and providing transaction service on the second server; wherein a time duration of each repeating step is necessarily shorter than a preceding repeating step, and transaction service on the second server is paused until the providing step.
This document play a vital role in the development of life cycle (SDLC) as it describes the complete requirement of the system. It means for use by developers and will be the basic during testing phase. Any changes made to the requirements in the future will have to go through formal change approval process.
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration models.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with a client reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project and implimentation, with an eye toward the end goal of the project and implimentation.
The steps for Spiral Model can be generalized as follows:
• The new system requirements are defined in as much details as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
• A preliminary design is created for the new system.
• A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
• A second prototype is evolved by a fourfold procedure:
1. Evaluating the first prototype in terms of its strengths, weakness, and risks.
2. Defining the requirements of the second prototype.
3. Planning an designing the second prototype.
4. Constructing and testing the second prototype.
• At the customer option, the entire project and implimentation can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer’s judgment, result in a less-than-satisfactory final product.
• The existing prototype is evaluated in the same manner as was the previous prototype, and if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
• The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
• The final system is constructed, based on the refined prototype.