I have a client that runs a 24/7 application on UniVerse (11.3.2).  They are conscientious about keeping their files well sized.  Several years ago they tried the CONCURRENT option on RESIZE and got badly burned when they ended up with corrupted files and lost data.  They have been very gun shy about using CONCURRENT since then.  Has anyone resized UniVerse files with the CONCURRENT option recently?  Is it stable now or is it still a crap shoot on the end result?  If you use it, what is the performance impact?

Why not make the files all DYNAMIC and never again have to worry about such things?

I have a client that runs a 24/7 application on UniVerse (11.3.2).  They are conscientious about keeping their files well sized.  Several years ago they tried the CONCURRENT option on RESIZE and got badly burned when they ended up with corrupted files and lost data.  They have been very gun shy about using CONCURRENT since then.  Has anyone resized UniVerse files with the CONCURRENT option recently?  Is it stable now or is it still a crap shoot on the end result?  If you use it, what is the performance impact?

I have a client that runs a 24/7 application on UniVerse (11.3.2).  They are conscientious about keeping their files well sized.  Several years ago they tried the CONCURRENT option on RESIZE and got badly burned when they ended up with corrupted files and lost data.  They have been very gun shy about using CONCURRENT since then.  Has anyone resized UniVerse files with the CONCURRENT option recently?  Is it stable now or is it still a crap shoot on the end result?  If you use it, what is the performance impact?

I have a client that runs a 24/7 application on UniVerse (11.3.2).  They are conscientious about keeping their files well sized.  Several years ago they tried the CONCURRENT option on RESIZE and got badly burned when they ended up with corrupted files and lost data.  They have been very gun shy about using CONCURRENT since then.  Has anyone resized UniVerse files with the CONCURRENT option recently?  Is it stable now or is it still a crap shoot on the end result?  If you use it, what is the performance impact?

While it's encouraging to hear other users state that they have not had any problem with the CONCURRENT option on the RESIZE command, I'd like to see a response from Rocket.  Are there any outstanding issues with its use?  Are there any situations where you would not recommend it?  At what release level do you endorse its use?

Hope this helps: There are a number of changes and fixes in RESIZE...CONCURRENT in the 11.3.1 and 12.2.1 release notices worth reviewing.

Regards

JJ

Hope this helps: There are a number of changes and fixes in RESIZE...CONCURRENT in the 11.3.1 and 12.2.1 release notices worth reviewing.

Regards

JJ

John,

Unfortunately the release notes don't address resizing hashed files.  I have sifted through the manuals and found that indexes have to be rebuilt when changing a file from 32bit to 64bit so I would assume indexes are safe for a simple modulo change or deleted space reclaim.  Another concern mentioned was potential issues when a file is opened and the file variable stored in common.  Have you run across this issue? 

Ultimately is comes down to Charles' comment, is it safe to use RESIZE...CONCURRENT on an active system?

The only reported issue with RESIZE CONCURRENT I am aware of is related to Replication. If RESIZE CONCURRENT is issued on a subscribed file AND the subscribed file is very busy being updated, record locks may be left behind on the subscribed file. These locks would need to be released with the UNLOCK command.

The reason for recommending indexes be recreated when a file is resized from 32bit to 64bit is size considerations. If the amount of data in the file requires a 64bit file, then the index may also require a 64bit file. This would be true whether or not the CONCURRENT keyword was used.

The above issue noted when running RESIZE CONCURRENT on the subscriber is being investigated for resolution. The issue can happen 11.3.x systems but is not present on 12.x.

For the UniData customers reading this thread.

There are no concerns about using RESIZE CONCURRENT on UniData.

Also if you change the bit type with RESIZE on UniData, the associated index if present is also changed to the new bit type.

To make with the use of RESIZE and RESIZE CONCURRENT a log file called resize.log in the bin directory that logs the start and end of a resize. The idea being that should the worst happen during a resize and the system does down, you can use the resize.log file to see which files may need attention.

Final note on RESIZE for UniData, if you are looking to resize dynamic files or resize to dynamic files do not use memresize, for more details refer to the knowledge base article on understanding dymanic files and the limits of memresize that I wrote.

We use RESIZE CONCURRENT, but sparingly.   We had a few issues with it when we first started using it, but that was on an older version.  We're on UniData 7.3.7 now, but old habits die hard.  We're moving to 8.2.4 soon, so we'll probably give CONCURRENT another serious look then.  I imagine that the problems we had initially have been addressed by now.

To avoid problems with CONCURRENT, we've followed these rules when resizing static hashed files:

1. Don't use it on really busy files.
2. Don't change the block size.
3. Don't make the modulo smaller.

We also don't use it on dynamic files, but only because our dynamic files are quite lumpy, which makes the resize immediately start splitting the file and we want to avoid that.

Note:  We're on HPUX Itanium.  A move to Linux is also in our future, after we move to 8.2.4.

@Dean Armbruster when you move to 8.2.4 you need to read up on the new dynamic split type called WHOLEFILE, the reason it was introduced was to avoid the split problem that KEYONLY and KEYDATA have. I've written some technotes about this and have several presentations on the subject. I think I mentioned one earlier in this thread about understanding how dynamic files work and the limitations of memresize.

If anyone else wants that information, reply to this message in the forum and and I'll look at getting it shared in this forum in some shape.

@Dean Armbruster when you move to 8.2.4 you need to read up on the new dynamic split type called WHOLEFILE, the reason it was introduced was to avoid the split problem that KEYONLY and KEYDATA have. I've written some technotes about this and have several presentations on the subject. I think I mentioned one earlier in this thread about understanding how dynamic files work and the limitations of memresize.

If anyone else wants that information, reply to this message in the forum and and I'll look at getting it shared in this forum in some shape.

Hi Jonathan,

I want the information about WHOLEFILE. Can you please share it here or email me?

Regards,

Milind