What is your favorite way to resize and how often do you do it?

Is the F-RESIZE, FILE-SAVE, then restore the *best* way?

If it is, it seems a bit impractical to take a 24/7 production system
offline for 3 to 4 hours, plus I'd rather not give up every weekend to
do this chore.


Thanks,
Danny

"ddspell-m3" wrote
happen more than twice a year, or you're not oversizing big enough.

You could manually save/restore just one account, or
save/delete/create/restore a handfull of large files, as sort of a stop-gap
measure if you can't budget enough down-time to do a full save/restore
-- if your overflow {alias "FREE"} space isn't too fragmented already.
This goes nicely with using big disk files instead of tapes to do the backup,
as there's not that worry about 2gig or 4gig filesize limits on certain platforms
if you're just doing a partial backup for resizing; real tapes are sooo slow.

On Unidata i run a guide once a week and if anything is rather bad it
will be resized useing one of the resize tools. As said above, if you
are carefull on how you size files, they should not need resizing very
often. I also use dynamic files for any rappidly changing files as it
is much easier....


Frank Winans wrote:

look at "resize-file" command, which works on a file by file basis -
and can be used while files are being used.

As your system has been in use for a while, I'd suggest your files are
somewhat "static", or at least "relatively" slow growing, so would only
need "attention" every few months.

We have utilities that resize files ovenight - one at a time, and only
for files that are more than "X%" undersized - you can write your own
resizer to do this with "smarts" appropriate to your application (or
not), which you can run on an "as required" basis.

Full system backup/restore can tghen be postponed till "every other
year"

Different kettle of fish for new installs with rapid growth ...


Ross Ferris
Stamina Software
Visage > Better by Design!

I've always used the recommended modulo from ISTAT, but for
transactional files that grow quickly, it is hard to keep the right
modulo.

I take it from what everyone is saying that it is better to oversize.
I guess they only downside to this is that if the file is oversized and
the file is not growing, then there are extra groups that will be
processed whenver a query is done plus the extra groups take up space
due to group allocations.

On a growing file, how much do you oversize? ...10%? ...25%?
....100%? ...more?

When calculating a new modulo, is it necessary or recommended to use a
prime number?


Regards,
Danny

Why not do a little arithmetic?

Get the average byte size of a record. Then estimate how many records
you think will in be in the file in, let's say, 2 months (if that's your
time frame for revisiting your modulos). Multiply the average byte size
by the number of the records. That's the total byte size of the file in
2 months. Divide that by your frame size (1K, 2K, 4K, or whatever) and
you have the number of contiguous frames you would need to pack all that
info into. Then play around with modulos around that number to see which
one gives you a nice record spread. (On D3/NT there is a hash-test
facility in the File Manager. Other MV implementaions would have their
own hash testing facilities.)

If you're OK with going into overflow for each group, you could cut your
number in half. It all depends how much your app would be hurt having to
read from overflow. That's a judgement call.

Sholom

ddspell-m3 wrote:

ddspell-m3 wrote:
Always recommended, sometimes necessary.
On a uniData system:

:CREATE-FILE DICT TEST.MODULO 6
Create file D_TEST.MODULO, modulo/6,blocksize/1024

:CREATE-FILE DATA TEST.MODULO 6
6 is not a prime number, modulo changed to 7.
Create file TEST.MODULO, modulo/7,blocksize/1024

(Actually, I expected the DICT would be changed to
modulo 7!)

--
frosty

I only use a full save/restore to defrag (if you resize a large file
during the restore, the restore process can take hours longer). I
resize files with the resize command, typically allocating at least 25%
excess (sometimes 50%- disk is cheap!). I never use the "w" option with
the d3 resize command, it is slow enough already. (I have never had
contention problems with resizing a D3 file, but on UV I do the
resizing during off-hours without the CONCURRENT (?) option - of course
D3 goes faster too if the system is mostly idle, but as I mentioned it
does not seem to be necessary.)

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Is it possible to file save/restore a database account under a new
name, then delete the old account, then rename the new account to the
old account name?

Is there a rename-account TCL command?


Regards,
Danny

ddspell-m3 wrote:
Danny,

I suggest you rtfm or at least install the D3 help (ref) account. If
you don't know how then google this group for instructions.

What you are looking for is move-file.

:help move-file

d3.doc 'tcl.move-file' size = 2105
d3.doc tcl.move-file
token move-file
syntax move-file file.reference {file.name}
to: (file.reference {file.name}
category TCL
type Verb
terse Moves file.
desc moves a file descriptor from one dictionary to another.
The
dictionary may be file-level, account-level (master
dictionary)
or system-level (mds or system).

The verb requests the destination dictionary with the
prompt
'TO:'. The following responses are allowed:

(dict.name
-or-
(dict.name file.name
-or-
file.name

If the "dict.name" is missing, the source file dictionary
is
assumed.

If the "file.name" is missing, the source "file.name" is
assumed.

If both the "dict.name" and the "file.name" are omitted,
no
action is taken.

"move-file" follows a hierarchical approach to file
transfer. A
file must be moved to the SAME LEVEL as it was created.
That is,
a data file to a data file, master dictionary to master
dictionary, and so on.
options
see.also create-file (TCL)
steal-file (TCL)
:swe (R83) (TCL)
:swx (R83) (TCL)
copy (TCL)
files (Definitions)
delete-file (TCL)
:swd (R83) (TCL)
rename-file (TCL)
create-bfile (R83) (TCL)
file control block (Definitions)

to: old.bp

This effectively changes the name of the data-level
d-pointer
for the "bp" file to another item in the dict of bp called
"old.bp". "old.bp" would subsequently be available using
the
reference "bp,old.bp". This also removes the "default"
d-pointer
to the "bp" file, and any reference to the "bp" data
section
would result in the message, "data level descriptor
missing".

move-file md bp
to: old.bp

This changes the "bp" file to "old.bp". Note: this does
NOT
change the name of the data file within the dictionary of
"bp".

move-file md bp
toarchive,,

This moves the "bp" file from the current account to the
"archive" account md.

move-file dict bp bp


move-file md bp
toarchive,,

This moves the "bp" file from the current account to the
"archive" account md.

move-file dict bp bp
todict archive,bp,old.bp,

This moves the data portion of the "bp" file from the
current
account to the account called "archive", to a dictionary
called
"bp", and renames it "bp.old".

move-file mds,, pa
toete

This renames the account "pa" to "pete". Note:
"rename-file"
does not work at the mds ("system") level.
warnings
compat D3 7.0
AP
print.rules


/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006