The loading of the car insurance data has gone totally wrong.
An unidentified problem in GIS has messed up over 11 hours of AS/400 work.
When trying the exact same loading during the day it went just fine, it's one of these awkward problems that happens too many times during the GIS data loading and that no one ever knows the cause...
This will force this migration to be pushed, since car insurances will have to be loaded again during the weekend.
I will be following closely this migration during the weekend.
If some more problems arise I'll be the first one to know and I'll sound the alarms.
I have scheduled a set of checkpoints during the weekend, starting Saturday early and ending Sunday night.
Showing posts with label loader. Show all posts
Showing posts with label loader. Show all posts
Thursday, December 23, 2010
Thursday, March 25, 2010
Day 358 - Go Live Files Ready
We have received the source files and have loaded them into our staging area.
We have executed the data migration for the entities and created the GIS loading files required for the go live.
The files have been loaded in the quality acceptance environment without a single problem. Tomorrow the testing team will check if everything is in order and, if so, the data will be loaded on the day after.
We have executed the data migration for the entities and created the GIS loading files required for the go live.
The files have been loaded in the quality acceptance environment without a single problem. Tomorrow the testing team will check if everything is in order and, if so, the data will be loaded on the day after.
Wednesday, January 6, 2010
Day 279 - Happy New Year and Happy News
Clients are now being loaded with a marginal number of rejections.
The GIS configuration issues still have an impact but that problem is being solved quickly.
I'm still around the report load query problem, but it is not easy to test the performance on a slow system, since it takes too much time to process a query and return its result.
The GIS configuration issues still have an impact but that problem is being solved quickly.
I'm still around the report load query problem, but it is not easy to test the performance on a slow system, since it takes too much time to process a query and return its result.
Day 273 - Configuration Issues
The GIS configuration is changing and that has a direct impact in the mapping rules.
We are now facing an increase number of data being rejected by GIS because its configuration has been changed but the mapping hasn't.
We are now facing an increase number of data being rejected by GIS because its configuration has been changed but the mapping hasn't.
Day 266 - Christmas Break
The project will be stopped for a short Christmas break.
The overall number of data being rejected by the GIS loader is decreasing every day.
But we are now facing a performance problem again. It takes too much time to query GIS in order to know how many errors and what time of errors occurred in the loading procedure. I'll have to take a look at these query performance so that the loading report does not take half-day for a simple auto claim data load.
The overall number of data being rejected by the GIS loader is decreasing every day.
But we are now facing a performance problem again. It takes too much time to query GIS in order to know how many errors and what time of errors occurred in the loading procedure. I'll have to take a look at these query performance so that the loading report does not take half-day for a simple auto claim data load.
Day 264 - Error Free Loading
Finally we are start to get error free data loading.
Some types of clients are already loading into GIS and this is reducing the number of claims rejected by the GIS loader.
I'm expecting to stop worrying with client problems soon.
Some types of clients are already loading into GIS and this is reducing the number of claims rejected by the GIS loader.
I'm expecting to stop worrying with client problems soon.
Day 245 - Testing team
Management has finally assigned a test team to working half-day every day.
This is taking the tests to cruse speed.
Every day there are problems detected, rules changed and minor changes that have a great impact on the migration. The number of rejected records by the GIS data loader is starting to decrease.
This is taking the tests to cruse speed.
Every day there are problems detected, rules changed and minor changes that have a great impact on the migration. The number of rejected records by the GIS data loader is starting to decrease.
Wednesday, November 18, 2009
Day 232 - Loading Perfomance Problem
Finally we were able to start the load of the last weekend data into GIS for testing purposes.
The entities were loaded with less than five thousand rejects on a near one million records.
It is not a bad ratio, but I was expecting a lower rejection rate by now.
The loading of a subset of the car insurance claims, around 450000 records, as also started.
Most of car insurance claims are loading without errors, but a critical problem has raised.
GIS is loading around 2100 records per hour.
This means that 50000 records will require 24 hours to load, and the full set will require an impossible 10 days to be accomplished.
This is sequential time, but even if we use 6 CPUs at a time it will still require more than one day and a half to accomplish this task. Plus, the AS/400 were GIS is running is unavailable 3 hours every night for maintenance procedures.
This is more than a technical challenge, it is a critical situation that will require the involvement of management in the process of finding a solution.
The entities were loaded with less than five thousand rejects on a near one million records.
It is not a bad ratio, but I was expecting a lower rejection rate by now.
The loading of a subset of the car insurance claims, around 450000 records, as also started.
Most of car insurance claims are loading without errors, but a critical problem has raised.
GIS is loading around 2100 records per hour.
This means that 50000 records will require 24 hours to load, and the full set will require an impossible 10 days to be accomplished.
This is sequential time, but even if we use 6 CPUs at a time it will still require more than one day and a half to accomplish this task. Plus, the AS/400 were GIS is running is unavailable 3 hours every night for maintenance procedures.
This is more than a technical challenge, it is a critical situation that will require the involvement of management in the process of finding a solution.
Tuesday, November 17, 2009
Day 230 - Test Team Assembled
Finally the test team has been defined and the tests will start, with a a two week delay.
Unfortunately, the data we've tried to load into GIS this weekend was almost entirely rejected.
We don't know what has happened but the loading logs indicate a change in the system configuration. This means that almost all the data that was already being loaded without problems, was rejected!
There is also a great side effect about this, the testing team has no data to test.
We hope this will be fixed soon.
Unfortunately, the data we've tried to load into GIS this weekend was almost entirely rejected.
We don't know what has happened but the loading logs indicate a change in the system configuration. This means that almost all the data that was already being loaded without problems, was rejected!
There is also a great side effect about this, the testing team has no data to test.
We hope this will be fixed soon.
Wednesday, October 21, 2009
Day 202 - Firts Entity Migration Test Results
As expected, we did had a low error rate.
Overall, we got less than 1% of data that has been rejected, meaning that 99% of the data has been correctly migrated.
The numbers say it all, less than 6000 records rejected over 6 different types of errors.
We had the data slit into 11 files, to allow parallel loading, which took an average of 45 minutes each file.
The bad news is that the GIS loading procedure took, sequentially, 490 minutes and it hardly will be capable of loading more than 4 files at the same time.
As always, the next days will result on transformation rules change requests.
Overall, we got less than 1% of data that has been rejected, meaning that 99% of the data has been correctly migrated.
The numbers say it all, less than 6000 records rejected over 6 different types of errors.
We had the data slit into 11 files, to allow parallel loading, which took an average of 45 minutes each file.
The bad news is that the GIS loading procedure took, sequentially, 490 minutes and it hardly will be capable of loading more than 4 files at the same time.
As always, the next days will result on transformation rules change requests.
Day 199 - Firts Entity Migration Test
Today the entities, clients only, will be migrated for the first time for real.
The data transformation process itself is quite fast, less than 500000 records will be transformed in less than 30 minutes, but them we have to create structured files that gather all the transformed information into GIS the loading file format, and that will take around an hour.
I believe in a low error number from this first real client migration test, but the results will only be available Monday.
The data transformation process itself is quite fast, less than 500000 records will be transformed in less than 30 minutes, but them we have to create structured files that gather all the transformed information into GIS the loading file format, and that will take around an hour.
I believe in a low error number from this first real client migration test, but the results will only be available Monday.
Monday, June 15, 2009
Day 76 - Back from Vacation
I've just came back from a one week vacation.
Unfortunately there's no real news.
It was still not possible to load data into the new DB2 on Windows. Since some field values hold the " character, the DB2 LOAD messes up the data when loading. A new field qualifier will be tried soon.
There was also a kick-off meeting for a new mapping for insurance claims programmed, but unfortunately it did not happened.
I still hope to have new mappings during this week, though.
Unfortunately there's no real news.
It was still not possible to load data into the new DB2 on Windows. Since some field values hold the " character, the DB2 LOAD messes up the data when loading. A new field qualifier will be tried soon.
There was also a kick-off meeting for a new mapping for insurance claims programmed, but unfortunately it did not happened.
I still hope to have new mappings during this week, though.
Subscribe to:
Posts (Atom)
Posts
