old style date/time field type conversion

Previous topic - Next topic

PBastien

   We are migrating to v9 shortly, and we plan on converting our application groups using old style date/time field types.  The process works well in our test environments with a low volume of documents, however, I am wondering how long this process will take when processing our production tables and have found no information pertaining to performance of the date field type conversion process. 

   Our biggest Application group is composed of some 28,000,000 documents split in 3 DB2 tables (max 10,000,000 docs per table). This Appl.Grp contains 5 date fields to be converted to the new format.

   We plan on using the CMOD Adminitrator Client, and selecting the "Create/Use new style date/time field types in place of existing old style date/time field types" option for each application group to convert.   

   Based on this information, how long should I expect the conversion to take?

   Any tips/suggestions in converting date formats are welcome!  ;D


Alessandro Perucchi

Hello,

Well, to be honest I don't know! And to be dishonest, I don't know too :-D

What I can suggest, is to create a new instance of CMOD in your test environment, restore your production database there, configure this CMOD as "cache only" and don't configure TSM at all, and neither copy the cache at all... the idea is really to have a working Library Server without links to documents, just to "play" with your prod copied database in a safe environment.

And with this new instance, simply try to do the conversion, and have a feeling it will take seconds, minutes or weeks :-D

Of course, this is easy if you can do that. If for compliance and security reasons, you cannot copy a production database in Test environment... then you're out of luck...
And in that case, the only advice I could give you, would be to load fake documents in your Test environment, to have the same amount of documents (you can have documents which are only 1 byte, so you won't have the need to order new disk space, even for 30'000'000 documents! :-D)

Sincerely yours,
Alessandro
Alessandro Perucchi

#Install #Migrations #Conversion #Educate #Repair #Upgrade #Migrate #Enhance #Optimize #AIX #Linux #Multiplatforms #DB2 #Windows #Oracle #TSM #Tivoli #Performance #Audits #Customizing #Availability #HA #DR #JavaApi #ContentNavigator #ICN #WEBi #ODWEK #Services #PDF #AFP #XML

swat

Do one thing.. as this is only to test the conversion of dates..

1.create a new app grp, and load 1000 docs with having different dates (assuming you want to test the 1000 different types of dates i.e approx 3 years).
2.close the cmod table.
3.do the step 1 again ;D
4. do step 2 again ;D
5. do step 1 again ;D
6. do step 2 again. ;D

Now you have 3 tables having 1000-1000 rows.

download the table content to csv, and make same data copy till you get 10M rows in csv.
If you are using oracle then use sqlldr utility to load this 10M csv file to database. If DB2 then use DB2 load utility to all 3 AG data tables.

Now you are ready to do the testing..

Let us know the timing results.



PBastien

Thanks fellows!

   I guess I'll have to run those high volume performance tests after all!  :-\

   I'll let you know of the results...


Have a great weekend  ;D

PBastien

Hi folks,

    sorry, I didn't get around to post the results of my tests earlier... but since we have converted the production tables since, I can assure you that performance of the date conversion process is a non-issue. Our biggest application group, which was over 30,000,000 docs split in 4 tables was converted in less 6 seconds.

   btw, no problems were encountered during the process  ;D

Cheers!
Patrick