Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

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