Access Db to SQL Server Migration


Published on

A proposal to migrate a fairly successful Access Db, that trading assistants used to verify trades, to a SQL Server backend.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Access Db to SQL Server Migration

  1. 1. GM Unallocated / Unverified Databases Migration to SQL Server Produced by: TMG Control Risk Management
  2. 2. Current Technology and Process Current Output 5 7 SQL Migration - Merits 8 Background of Current Process 4 Migration Process 9 Planned Technology and Process 6 Overview 3
  3. 3. Considerations <ul><ul><li>The current process is stable but extending it to other regions will entail costs, complexity and potential downtime </li></ul></ul><ul><ul><li>Migration costs need to be balanced against support hours reduced, increased system accessibility, and increased system robustness </li></ul></ul><ul><ul><li>Migration brings potential benefits via web-based reporting options, broadening of development tools, and ease of future migration to a data warehouse. </li></ul></ul><ul><ul><li>Migration reduces operational risks associated with the current process, moving to a standard enterprise platform, and away from an older technology and key person dependencies, i.e., replication. </li></ul></ul>Overview
  4. 4. Unallocated & Unverified Trade Process & Reporting <ul><ul><li>Current Daily Process rolled out Aug-Sep 2007 </li></ul></ul><ul><ul><li>Unallocated Trade Process & Reporting </li></ul></ul><ul><ul><ul><li>Trades not allocated to client or still subject to client allocation </li></ul></ul></ul><ul><ul><ul><li>Trades booked to dummy, pending or suspense counterparties in FO systems </li></ul></ul></ul><ul><ul><ul><li>New Counterparties awaiting client opening procedures </li></ul></ul></ul><ul><ul><ul><li>Analysed by Age, Business, Location and Root Cause </li></ul></ul></ul><ul><ul><ul><li>Root Cause is analysed at a desk, trader, marketer level </li></ul></ul></ul><ul><ul><ul><li>Global daily MIS produced by TMG published to FO </li></ul></ul></ul><ul><ul><li>Unverified Trade Process & Reporting </li></ul></ul><ul><ul><ul><li>Trades entered into FO and risk management systems not fed downstream. </li></ul></ul></ul><ul><ul><ul><li>Awaiting Marketer and/or Trader Approval </li></ul></ul></ul><ul><ul><ul><li>Analysed by Age, Business, Location and Root Cause </li></ul></ul></ul><ul><ul><ul><li>Global daily MIS produced by TMG published to FO </li></ul></ul></ul><ul><ul><li>Aggregates inputs for 10 to 15 systems per database on Unverified and Unallocated trades </li></ul></ul><ul><ul><li>User Volume (TMG staff accessing the platforms): </li></ul></ul><ul><ul><ul><ul><ul><li>Unallocated - approximately 70 users per week, 30+ user per day </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Unverified - approximately 60 users per week, 30 user per day </li></ul></ul></ul></ul></ul>Background
  5. 5. Technology <ul><ul><li>Unverified – MS Access database with front-end (FE) and back-end (BE) components </li></ul></ul><ul><ul><li>Unallocated – MS Excel shared spreadsheet FE and MS Access database BE components </li></ul></ul><ul><ul><li>A project to convert Unallocated FE to MS Access is in UAT </li></ul></ul><ul><ul><li>Multiple access BE’s across locations that are synchronised using replication </li></ul></ul><ul><ul><li>Replication implemented through third party registered DLL </li></ul></ul><ul><ul><li>Each replicant BE is about 500Mb in size, each user’s FE is about 5Mb. </li></ul></ul>Technology and Process Current Process <ul><ul><li>Current Process requires 3 one-hour shutdown periods for synchronization @ 8 AM, 1 PM and 6 PM UK time </li></ul></ul><ul><ul><li>Current synchronisation between 2 user-accessed BE databases, one for NY, one for London, and one central database in London for the administrator </li></ul></ul><ul><ul><li>FTE’s 3 primary with one backup person for each. </li></ul></ul><ul><ul><ul><li>One to run import and data creation process in AM, generate report for Start-of-Business (SOB), and to run second 1 PM synch from London, </li></ul></ul></ul><ul><ul><ul><li>Second to run EOD synchronisation, as well as raw data generation for reporting from NY </li></ul></ul></ul><ul><ul><ul><li>Third person creates EOD reports from output. </li></ul></ul></ul><ul><ul><li>Process is now being run out of DBOI – Mumbai (for SOB) and looking to extend coverage over the current NY based - EOD reporting </li></ul></ul><ul><ul><li>Support for issues with databases provided out of NY (on call to support UK hours and NY EOD) </li></ul></ul>
  6. 6. Technology <ul><ul><li>MS Access front-end (FE) for administrator processing of imports </li></ul></ul><ul><ul><li>SQL Server – house/build end-user and reporting data </li></ul></ul><ul><ul><li>MS Access database FE </li></ul></ul><ul><ul><li>Excel for reporting, pulling data from SQL Server </li></ul></ul>Planned Technology and Process Process <ul><ul><li>Shutdown period of 8 to 9 AM UK to process and generate data </li></ul></ul><ul><ul><ul><li>Flexible, considering run from India, but limited because of file delivery times </li></ul></ul></ul><ul><ul><li>Data, modified, and archived on SQL Server </li></ul></ul><ul><ul><li>Shutdown period at 4 PM US (9 PM UK) for archiving processes </li></ul></ul><ul><ul><li>EOD/SOB reports can be maintained as is or advanced </li></ul></ul><ul><ul><ul><li>Generated as usual, but XLS pints to SQL Server, instead of Access Db </li></ul></ul></ul><ul><ul><ul><li>Automated via SQL-based tools generate SOB/EOD reports, either as e-Mail, or as web-based downloads </li></ul></ul></ul>
  7. 7. Output – Standard Reports, Primary Users, and Analysis Work <ul><li>Standard SOB reports for Unallocated and Unverified, with breaks counts and responses per region, managers, and business </li></ul><ul><li>Standard EOD reports for Unallocated and Unverified, similar to SOB reports but with KPI, graphical analysis and breakdowns of worst offending traders / marketers, and outstanding queries to be followed up by TMG or FO. </li></ul><ul><li>Unallocated and Unverified results are used in the daily Debt KPI and discussed in a weekly management meeting </li></ul><ul><li>Additional reports for other teams analyzing results, produced monthly and/or quarterly </li></ul>Current Output
  8. 8. SQL - Merits of Using / MIS Project Options / WRaP Migration <ul><ul><li>Unallocated and Unverified data is currently used in the WRaP process for all of the Debt business/locations, and for Equity Prop Trading (US) </li></ul></ul><ul><ul><li>Time involved in shutdown and replication would be reduced </li></ul></ul><ul><ul><ul><li>Reduction in staff hours devoted to synchronization and maintenance from 3 -4 hours to 1 </li></ul></ul></ul><ul><ul><ul><li>No increase in labor if regions are added, i.e., Frankfurt and Singapore </li></ul></ul></ul><ul><ul><li>More time can be utilized by users to make comments, without timing restrictions, except at the beginning and end of the day </li></ul></ul><ul><ul><li>Operational risk, e.g., process failure, and the time required by staff to resolve problems, would be reduced by the removal of synchronization from the process </li></ul></ul><ul><ul><li>Although the current Db works under 2007, a SQL server back-end eliminates risk associated with older Access Db functions, specifically replication </li></ul></ul><ul><ul><li>Preliminary testing of the FE migration has been promising, requiring very little work, although additional work might require some new coding to guarantee data integrity and conflict resolution </li></ul></ul><ul><ul><li>As for the import functions of Db, they can largely stay as is, with minor modification to repoint them to a SQL Server. </li></ul></ul><ul><ul><li>SQL Server provides a better upgrade path, as more than Access can be used for the front-end, as well as for reporting </li></ul></ul>SQL Migration - Merits
  9. 9. Elements <ul><ul><li>Changeover elements for modification, testing, and verification: </li></ul></ul><ul><ul><li>With VBA code modification, all imports must function </li></ul></ul><ul><ul><ul><li>It is fairly straightforward to recode VBA for SQL over Access </li></ul></ul></ul><ul><ul><ul><li>As an example, recoding a similar Db for the WRaP migration took one day </li></ul></ul></ul><ul><ul><li>Queries need to be rewritten as views and/or stored procedures </li></ul></ul><ul><ul><ul><li>Much of this is handled automatically with migration tools </li></ul></ul></ul><ul><ul><li>The VBA aging calculation needs to be rewritten as a SQL function </li></ul></ul><ul><ul><ul><li>Already done as pert of WRaP testing </li></ul></ul></ul><ul><ul><li>The user front-end needs some modification to access the SQL server </li></ul></ul><ul><ul><li>Additionally, several elements of the front-end will need to be verified: </li></ul></ul><ul><ul><ul><li>Performance testing will need to pass user acceptance for performance </li></ul></ul></ul><ul><ul><ul><li>Data integrity will need to be maintained </li></ul></ul></ul><ul><ul><li>If integrated security is used, an ACL will need to created and filled so that users can seamlessly access the SQL Server </li></ul></ul><ul><ul><ul><li>Alternatively, specific logon accounts can be used, but gets messy </li></ul></ul></ul>Migration Process