You may want to review the following problems that have been addressed. If you
are running the Recoverable File System (RFS), you will probably want to be at
UniData
release 7.3.3 before using RESIZE CONCURRENT on RFS files. This list was
extracted
from the publically available 7.3.3 and 7.2.13 release notes:
7.3.3 -----------------------------------------------------
Issue UDT-8887 - Problem Description
RFS -- When resizing a recoverable file with the CONCURRENT option, UniData
may not have removed the filename.resize work file when the RESIZE process
completed. The file was no longer visible at the operating-system level, but
the disk space used by the file was not released and made available.
This problem occurred because one or more of the RFS daemons did not close
the filename.resize file at the operating-system level. The problem was easily
encountered if the udtconfig N_SYNC parameter was set to a value greater
than 0. This problem has been fixed.
Issue UDT-9393 - Problem Description
RFS -- Prior to this release, UniData would not remove the temporary 'rsz'
file associated with the CONCURRENT RESIZE of a recoverable file until all
tm processes and UniData daemons released had closed their handle to the file.
The file will be now be removed within two cycles of cleanupd after the RESIZE
completes.
7.3.2 and 7.2.13 -------------------------------------------------------
Issue UDT-8069 - Problem Description
UniData -- Prior to this release, when performing RESIZE CONCURRENT on a
file in another directory on the same server (not located in the same
directory as the account's VOC file), an error message similar to the
following example was displayed:
EDEVdefault
Error when trying to rename the source file before move
back to the working tmp file.
Intact records can be found in /home/udtacct/TEST.resize
In case source file is damaged, it can be recovered from
/home/udtacct/TEST.resize.
This behavior required the user to use the RESTORE option to make the file
accessible again. This problem has been fixed in this release, which means
that RESIZE CONCURRENT can be run against these files. The error is no
longer displayed and the RESTORE option is no longer needed.
Issue UDT-8521 - Problem Description
UniData -- When resizing an encrypted file with the CONCURRENT option, the
resize operation failed and displayed an error message similar to the
following example:
In BP/_TEST2 at line 8 1:Grpno error. blkbuf->group=0, U_groupno=21, error
in U_blkread for file 'TRIGFILE3', key '', number=21
This problem occurred because an internal variable was overwritten, and has
been resolved.
UDT-8757 - Problem Description [7.3.x only - problem does not exist in 7.2.x]
RFS -- Before this release, all trigger information for a recoverable file
was lost after performing a RESIZE CONCURRENT. This problem has been fixed.
7.3.1 and 7.2.13 --------------------------------------------------------
Issue UDT-4352 - Problem Description
UniData -- If you issued the dbpause command while a recoverable file was
being resized with the CONCURRENT option, the dbpause command appeared to
hang and the following message appeared:
# dbpause
CheckPoint time before ForceCP: Mon Feb 13 13:22:51 2012
This problem has been fixed.
7.3.0 and 7.2.13 ------------------------------------------------------
UDT-4295 - Problem Description
UniData -- Before this release, if you specified an incorrect blocksize of
512 for a recoverable file when using RESIZE CONCURRENT to resize the file,
the resize process stopped, but the file remained in a resize state. Now,
UniData checks to make sure the blocksize specified is valid before beginning
the resize process.
7.2.12 -----------------------------------------------------------------
Issue UDT-4124 - Problem Description
UniData -- Before this release, if a dynamic file was being resized with
the RESIZE CONCURRENT command and the file contained many parts, a
message similar to the following example appeared and the resize operation
failed:
RESIZE CONCURRENT failed to set the FL_RESIZE_DONE bit
This problem occurred because UniData tried to set the resize done bit
in the file header, but the file had been temporarily closed. This
problem has been resolved.
Wally Terhune
Technical Support Engineer
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: u2.rocketsoftware.com
Rocket U2 Support: +1.800.729.3553
** Please note that I am only available on Tuesdays and Wednesdays. **
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeffrey Butera
Sent: Tuesday, March 05, 2013 1:43 PM
To: U2 Users List
Subject: [U2] Unidata RESIZE CONCURRENT
So is anyone using Unidata's RESIZE CONCURRENT in production environments? I
have a dedicated maintenance window, so performing regular file resizing
usually isn't a problem here but I'm considering moving over to using the
CONCURRENT feature - particularly if a fire crops up in our production
environment.
Just curious about people's experience with it and the possible impact on
performance in a production environment.
--
Jeffrey Butera, PhD
Associate Director for Applications and Web Services Information Technology
Hampshire College
413-559-5556
http://www.hampshire.edu
http://www.facebook.com/hampshirecollegeit
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
