-
Notifications
You must be signed in to change notification settings - Fork 1
Forest Client Database Migration Strategy
MCatherine edited this page Oct 11, 2022
·
29 revisions
Data Quality Issue
Database options
- Stay with Oracle
- Pros:
- No need to migrate data
- Only need to manage one database
- Cons:
- Take time to get full read/write access to the Oracle db
- If we want to improve the ER Model, hard to change the existing structure, it will affect other tables and existing users
- Expensive
- Pros:
- Create and use a new Postgres db
- Pros:
- Have full control of the db
- Could improve the ER Model as we like
- Cons:
- Need to transfer data from Oracle to Postgres
- Need think about data synchronize
- Need to think about the tables that CLIENT is using but doesn't own
- Pros:
Database Migration Options
-
Case one: We publish the new application, but not ready to retire the old application
- not recommend, hard to manage two database behind
-
Case two: All the target users switch to use the new CLIENT application once we publish, and related applications switch to read from the new Postgres db, or use forest client API
- ideal, but hard to promise
-
Case three: All the target users switch to use the new CLIENT application once we publish, but still have related applications read from Oracle db
- very likey, will be our start point
-
Case four: All the target users switch to use the new CLIENT application, but some related applications still read and write into Oracle db
- possible, but not very likely
- check the Power BI report for client tables usage for last 4 weeks, not found any other application is writing into the client tables
- if we could keep checking the client tables usage for the next 3 month
- if still not found:
- when we publish the new app, disable all the write access for Oracle client tables
- if break any app, we provide an API to them
- this will be like case three
- if found any:
- it could be just 1 or 2 or a few tables, won't be too hard to do data sync
- so it will be like case three, with some additional care for a certain tables
- for example: when write into Postgres, write into Oracle as well, so for that certain table, only bring data from Oracle to Postgres
- if still not found:
How We Work with Two Databases
- Use Postgres for new CLIENT application, read/write
- Sync Postgres data back to Oracle, so keep Oracle up to date
- For some external tables like ORG_UNIT, if still use them, could get a proxy account to read from Oracle, or ask them to provide an API
Database Migration Method
- Copy data over initially (one-time):
- FME Desktop: desktop tools that is very powerful for data transferring, support renaming, restructuring, speed is fast, but need to learn the tool
- ora2pg: command line tools to copy Oracle data to Postgres, support simple data transfer, but not that powerful, installation process is not very easy for new user who doesn't know this tool
- Plain function in application: read from one database and do insert in another, have fully control of the data structure, but takes a lot of time
- Do data synchronize if need:
- Plain function in application: setup cron job daily to read from one database for any new/update record from yesterday, and do insert/update in another. We're not expecting a lot of new data everyday, so speed should be fine, but need to write code for each table
- FME Server with API: could support schedule jobs in openshift, but need to learn the FME Server, and how to do data merge with FME
- NATS: two way real time data synchronize tool, need to learn
Our Next Steps (start based on case three, all users will use the new CLIENT application, all the rest related apps just read from Oracle)
- Start by creating the new ER Model in Postgress for FOREST_CLIENT, CLIENT_TYPE_CODE, CLIENT_STATUS_CODE
- Copy the Oracle data into the Postgres db using FME Desktop
- Keep regular development, and check the client table usages montly
- Once get write access to Oracle db, investigate method to sync data from Postgres to Oracle, very likely will be writing plain functions in our application
Questions:
- For applications which use forest client data, do they just have read access? or they have write access as well? which tables are they using?
Power BI report only shows the client table usage for the last 4 weeks. So far only found tables are read by other apps, no write access for other apps - For external tables CLIENT are using, can we know how they are used? do we know which attribute in each table it actually looks for?
They do read only, so we could get a proxy account to still read from Oracle - If it's better to bring all tables own by CLIENT to Postgres all at once? or bring as need? Bring needed ones first
- Why some table client only has select access? Power BI report only shows the client table usage for the last 4 weeks, so it could have other access in other time
- We don't have access to read external tables Could request a new proxy account for reading specific external tables
Client Table Analysis
Missing
CLIENT_AUDIT_CODE (not in use),
EXTERNAL_CLIENT_REORG_RESULT (not in use),
EXTERNAL_CLIENT_REORG_SYSTEM (not in use),
all REORG tables are not in use any more,
NURSERY_LOCATION (external, owns by SPAR)
31 tables below:
Table name | Used by which app/Access |
---|---|
BUSINESS_CONTACT_CODE | CLIENT(select) |
CLIENT_ACTION_REASON_XREF | CLIENT(select) |
CLIENT_CONTACT | CLIENT(select/insert/update), SCS(select), GAS2(select) |
CLIENT_DOING_BUSINESS_AS | CLIENT(select) |
CLIENT_DOING_BUSINESS_AS_AUDIT | CLIENT(select) |
CLIENT_ID_TYPE_CODE | CLIENT(select) |
CLIENT_LOCATION | CLIENT(select/insert/update), THE schema(select/update, this is very likely a manual update, not through any application), select only for all other apps |
CLIENT_RELATIONSHIP_CODE | CLIENT(select) |
CLIENT_RELATIONSHIP_TYPE_XREF | CLIENT(select) |
CLIENT_STATUS_CODE | CLIENT(select), CBR(select) |
CLIENT_TYPE_CODE | CLIENT(select), HBS(select) |
CLIENT_TYPE_COMPANY_XREF | CLIENT(select) |
CLIENT_UPDATE_ACTION_CODE | CLIENT(select) |
CLIENT_UPDATE_REASON | CLIENT(select/insert) |
CLIENT_UPDATE_REASON_CODE | CLIENT(select) |
CLI_CON_AUDIT | CLIENT(insert) |
CLI_LOCN_AUDIT | CLIENT(select/insert) |
FOREST_CLIENT | CLIENT(select/insert/update), select only for all other apps |
FOR_CLI_AUDIT | CLIENT(select/insert), FREP(select) |
MAILING_CITY | CLIENT(select) |
MAILING_COUNTRY | CLIENT(select) |
MAILING_PROVINCE_STATE | CLIENT(select) |
MAX_CLIENT_NMBR | CLIENT(update) |
MOF_USER_ORG_DEFAULT (external table) | FTA(select/insert/update), select only for all other apps |
ORG_UNIT (external table) | select only for all apps |
REGISTRY_COMPANY_TYPE_CODE | CLIENT(select) |
RELATED_CLIENT | CLIENT(select/insert/delete), FTA(select) |
REL_CLI_AUDIT | CLIENT(select/insert) |
CLIENT_ACRONYM | select only for all apps |
V_CLIENT_PUBLIC | select only for all apps |