| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 339.1 | Yes, Offline | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Mar 17 1997 15:18 | 10 |
|
: Is the CONVERT still the way to go?
Yes. (EDIT/FDL can be used to tailor an FDL file for the conversion
operation.)
: On-line or not??
If I were asking this question, I'd handle this conversion offline.
|
| 339.2 | CONVERT/SHARE | GIDDAY::GILLINGS | a crucible of informative mistakes | Mon Mar 17 1997 23:45 | 6 |
| You can do the CONVERT itself "on line" provided you use /SHARE. Assuming
nobody is creating or deleting accounts at the time, the worst that will
happen is a few login dates, mail counts or password changes might be missed.
You will need to reboot in order to ensure that all OpenVMS components use
the same UAF.
John Gillings, Sydney CSC
|
| 339.3 | Did the ANAL/RMS/FDL and CONVERT and now... | CHOWDA::GLICKMAN | writing from Newport,RI | Tue Mar 18 1997 13:44 | 356 |
| I did an ANAL/RMS/FDL before, then the CONVERT and an ANAL/RMS/FDL on the new
SYSUAF.DAT. I have included the two FDLs before and after.
I have a couple of questions:
(1) any changes I can make to this FDL to tune the SYSUAF.DAT?
(2) can someone explain why on the new FDL the third key is
uninitialized? Is this a problem?
Thanks,
Here's the FDL of the SYSUAF.DAT before I did the CONVERT:
IDENT "18-MAR-1997 10:14:44 OpenVMS ANALYZE/RMS_FILE Utility"
SYSTEM
SOURCE OpenVMS
FILE
ALLOCATION 2820
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 3
CLUSTER_SIZE 4
CONTIGUOUS no
EXTENSION 12
FILE_MONITORING no
GLOBAL_BUFFER_COUNT 4
NAME "USER$DISK:[LFG]SYSUAF.DAT;6"
ORGANIZATION indexed
OWNER [GLICKMAN]
PROTECTION (system:RWED, owner:RWED, group:, world:)
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL none
FORMAT variable
SIZE 1412
AREA 0
ALLOCATION 2442
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 3
EXTENSION 12
AREA 1
ALLOCATION 30
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 3
EXTENSION 3
AREA 2
ALLOCATION 338
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 3
EXTENSION 18
KEY 0
CHANGES no
DATA_KEY_COMPRESSION yes
DATA_RECORD_COMPRESSION yes
DATA_AREA 0
DATA_FILL 100
DUPLICATES no
INDEX_AREA 1
INDEX_COMPRESSION yes
INDEX_FILL 100
LEVEL1_INDEX_AREA 1
NAME "Username"
NULL_KEY no
PROLOG 3
SEG0_LENGTH 32
SEG0_POSITION 4
TYPE string
KEY 1
CHANGES yes
DATA_KEY_COMPRESSION no
DATA_AREA 2
DATA_FILL 100
DUPLICATES yes
INDEX_AREA 2
INDEX_COMPRESSION no
INDEX_FILL 100
LEVEL1_INDEX_AREA 2
NAME "UIC"
NULL_KEY no
SEG0_LENGTH 4
SEG0_POSITION 36
TYPE bin4
KEY 2
CHANGES yes
DATA_KEY_COMPRESSION no
DATA_AREA 2
DATA_FILL 100
DUPLICATES yes
INDEX_AREA 2
INDEX_COMPRESSION no
INDEX_FILL 100
LEVEL1_INDEX_AREA 2
NAME "Extended User Identifier"
NULL_KEY no
SEG0_LENGTH 8
SEG0_POSITION 36
TYPE bin8
KEY 3
CHANGES yes
DATA_KEY_COMPRESSION no
DATA_AREA 2
DATA_FILL 100
DUPLICATES yes
INDEX_AREA 2
INDEX_COMPRESSION no
INDEX_FILL 100
LEVEL1_INDEX_AREA 2
NAME "Owner Identifier"
NULL_KEY yes
NULL_VALUE 0
SEG0_LENGTH 8
SEG0_POSITION 44
TYPE bin8
ANALYSIS_OF_AREA 0
RECLAIMED_SPACE 0
ANALYSIS_OF_AREA 1
RECLAIMED_SPACE 0
ANALYSIS_OF_AREA 2
RECLAIMED_SPACE 0
ANALYSIS_OF_KEY 0
DATA_FILL 41
DATA_KEY_COMPRESSION 73
DATA_RECORD_COMPRESSION 69
DATA_RECORD_COUNT 2144
DATA_SPACE_OCCUPIED 2433
DEPTH 2
INDEX_COMPRESSION 70
INDEX_FILL 61
INDEX_SPACE_OCCUPIED 27
LEVEL1_RECORD_COUNT 811
MEAN_DATA_LENGTH 710
MEAN_INDEX_LENGTH 34
ANALYSIS_OF_KEY 1
DATA_FILL 43
DATA_KEY_COMPRESSION 0
DATA_RECORD_COUNT 2147
DATA_SPACE_OCCUPIED 132
DEPTH 1
DUPLICATES_PER_SIDR 2
INDEX_COMPRESSION 0
INDEX_FILL 17
INDEX_SPACE_OCCUPIED 3
LEVEL1_RECORD_COUNT 42
MEAN_DATA_LENGTH 13
MEAN_INDEX_LENGTH 6
ANALYSIS_OF_KEY 2
DATA_FILL 43
DATA_KEY_COMPRESSION 0
DATA_RECORD_COUNT 2147
DATA_SPACE_OCCUPIED 171
DEPTH 1
DUPLICATES_PER_SIDR 2
INDEX_COMPRESSION 0
INDEX_FILL 36
INDEX_SPACE_OCCUPIED 3
LEVEL1_RECORD_COUNT 55
MEAN_DATA_LENGTH 17
MEAN_INDEX_LENGTH 10
ANALYSIS_OF_KEY 3
DATA_FILL 74
DATA_KEY_COMPRESSION 0
DATA_RECORD_COUNT 3
DATA_SPACE_OCCUPIED 9
DEPTH 1
DUPLICATES_PER_SIDR 286
INDEX_COMPRESSION 0
INDEX_FILL 1
INDEX_SPACE_OCCUPIED 3
LEVEL1_RECORD_COUNT 1
MEAN_DATA_LENGTH 1129
MEAN_INDEX_LENGTH 10
-----------------------------------------------------------------------
Here's the FDL of the SYSUAF.NEW after I did the CONVERT:
IDENT "18-MAR-1997 10:24:50 OpenVMS ANALYZE/RMS_FILE Utility"
SYSTEM
SOURCE OpenVMS
FILE
ALLOCATION 2816
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 3
CLUSTER_SIZE 4
CONTIGUOUS no
EXTENSION 12
FILE_MONITORING no
GLOBAL_BUFFER_COUNT 4
NAME "USER$DISK:[LFG]SYSUAF.NEW;1"
ORGANIZATION indexed
OWNER [GLICKMAN]
PROTECTION (system:RWED, owner:RWED, group:, world:)
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL none
FORMAT variable
SIZE 1412
AREA 0
ALLOCATION 2444
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 3
EXTENSION 12
AREA 1
ALLOCATION 32
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 3
EXTENSION 3
AREA 2
ALLOCATION 340
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 3
EXTENSION 18
KEY 0
CHANGES no
DATA_KEY_COMPRESSION yes
DATA_RECORD_COMPRESSION yes
DATA_AREA 0
DATA_FILL 100
DUPLICATES no
INDEX_AREA 1
INDEX_COMPRESSION yes
INDEX_FILL 100
LEVEL1_INDEX_AREA 1
NAME "Username"
NULL_KEY no
PROLOG 3
SEG0_LENGTH 32
SEG0_POSITION 4
TYPE string
KEY 1
CHANGES yes
DATA_KEY_COMPRESSION no
DATA_AREA 2
DATA_FILL 100
DUPLICATES yes
INDEX_AREA 2
INDEX_COMPRESSION no
INDEX_FILL 100
LEVEL1_INDEX_AREA 2
NAME "UIC"
NULL_KEY no
SEG0_LENGTH 4
SEG0_POSITION 36
TYPE bin4
KEY 2
CHANGES yes
DATA_KEY_COMPRESSION no
DATA_AREA 2
DATA_FILL 100
DUPLICATES yes
INDEX_AREA 2
INDEX_COMPRESSION no
INDEX_FILL 100
LEVEL1_INDEX_AREA 2
NAME "Extended User Identifier"
NULL_KEY no
SEG0_LENGTH 8
SEG0_POSITION 36
TYPE bin8
KEY 3
CHANGES yes
DATA_KEY_COMPRESSION no
DATA_AREA 2
DATA_FILL 100
DUPLICATES yes
INDEX_AREA 2
INDEX_COMPRESSION no
INDEX_FILL 100
LEVEL1_INDEX_AREA 2
NAME "Owner Identifier"
NULL_KEY yes
NULL_VALUE 0
SEG0_LENGTH 8
SEG0_POSITION 44
TYPE bin8
ANALYSIS_OF_AREA 0
RECLAIMED_SPACE 0
ANALYSIS_OF_AREA 1
RECLAIMED_SPACE 0
ANALYSIS_OF_AREA 2
RECLAIMED_SPACE 0
ANALYSIS_OF_KEY 0
DATA_FILL 90
DATA_KEY_COMPRESSION 74
DATA_RECORD_COMPRESSION 69
DATA_RECORD_COUNT 2144
DATA_SPACE_OCCUPIED 1071
DEPTH 2
INDEX_COMPRESSION 67
INDEX_FILL 66
INDEX_SPACE_OCCUPIED 12
LEVEL1_RECORD_COUNT 357
MEAN_DATA_LENGTH 710
MEAN_INDEX_LENGTH 34
ANALYSIS_OF_KEY 1
DATA_FILL 95
DATA_KEY_COMPRESSION 0
DATA_RECORD_COUNT 2119
DATA_SPACE_OCCUPIED 57
DEPTH 1
DUPLICATES_PER_SIDR 0
INDEX_COMPRESSION 0
INDEX_FILL 8
INDEX_SPACE_OCCUPIED 3
LEVEL1_RECORD_COUNT 19
MEAN_DATA_LENGTH 13
MEAN_INDEX_LENGTH 6
ANALYSIS_OF_KEY 2
DATA_FILL 99
DATA_KEY_COMPRESSION 0
DATA_RECORD_COUNT 2119
DATA_SPACE_OCCUPIED 72
DEPTH 1
DUPLICATES_PER_SIDR 0
INDEX_COMPRESSION 0
INDEX_FILL 16
INDEX_SPACE_OCCUPIED 3
LEVEL1_RECORD_COUNT 24
MEAN_DATA_LENGTH 17
MEAN_INDEX_LENGTH 10
ANALYSIS_OF_KEY 3
! This index is uninitialized - there are no records.
|
| 339.4 | tune for what? | GIDDAY::GILLINGS | a crucible of informative mistakes | Tue Mar 18 1997 17:55 | 21 |
| Lynn,
> (1) any changes I can make to this FDL to tune the SYSUAF.DAT?
What operations do you want to "tune" it *for*. Optimal tuning for one
system is not necessarily optimal for any other system. You need to
explain what the circumstances are (size of file, distribution of keys,
frequency of access, types of access etc...), what it is you want to
improve and what sort of maintenance load you're prepared to accept.
Look at it this way, if there were a "universal" tuning for the UAF there
wouldn't be anything to be "tuned", because it would all be hard coded.
> (2) can someone explain why on the new FDL the third key is
> uninitialized? Is this a problem?
More than likely it means that all records have null values for that
key. I'm not sure what "Owner Identifier" is used for, but whatever it
is, I don't think it's important.
John Gillings, Sydney CSC
|
| 339.5 | Tune for optimum based on number of records?? | CHOWDA::GLICKMAN | writing from Newport,RI | Wed Mar 19 1997 15:25 | 9 |
| re .4
I initially think I was thinking about the current size of the
file (number of records in it). The number of accesses is interesting
to consider as well. How do I get that?
With these in mind would I want to make adjustments to the .FDL?
Thanks,
|
| 339.6 | FDL, EDIT/FDL, Global Buffers, File Statistics | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Wed Mar 19 1997 15:43 | 26 |
| : I initially think I was thinking about the current size of the
: file (number of records in it).
How many records are present in the SYSUAF file?
When most folks consider tuning SYSUAF, they are usually looking
for speed, and are willing to trading off increased file size for
the increased speed.
In general, one should follow the criteria set forth with the
EDIT/FDL tool. (See the FDL, CREATE/FDL, and EDIT/FDL tools in
the _OpenVMS Record Management Utilities Reference Manual_.) The
EDIT/FDL tool contains support for prompting a user with a script
of questions to better optimize the file for local requirements.
On a more general note, global buffers can sometimes help reduce
the file access I/O, by tending to share the RMS file cache among
multiple processes, and by tending to keep the cache in host memory.
See the SET FILE/GLOBAL_BUFFER command. (This trades off I/O for
memory.)
: The number of accesses is interesting to consider as well.
: How do I get that?
See the SET FILE/STATISTICS command, among other tools.
|
| 339.7 | "Number of records" isn't an operation | WIBBIN::NOYCE | Pulling weeds, pickin' stones | Wed Mar 19 1997 15:45 | 8 |
| "What operations do you want to optimize for?" is asking you to choose between
tuning for
- speed of login
- speed of adding new users
- etc.
which may conflict with each other.
Are you seeing a problem? What is it?
|
| 339.8 | | AUSS::GARSON | DECcharity Program Office | Wed Mar 19 1997 20:59 | 13 |
| re .0
Given the vagueness of the tuning requirements you would want to use
$ ANAL/RMS/FDL/OUTPUT=xxx.FDL IN.DAT
$ EDIT/FDL/NOINTER/ANAL=xxx.FDL xxx.FDL
$ CONVERT/FDL=xxx.FDL IN.DAT OUT.DAT
The above commands make assumptions on your behalf about what you are
trying to improve and what tradeoffs you are prepared to make.
I personally would not do this online.
|