<<< TEMBEL::OFFICE$DISK:[NOTES$LIBRARY]INFORMATION_SYSTEMS.NOTE;1 >>> -< The Information Systems SIG >- ================================================================================ Note 1.0 Welcome ... No replies BIGUN::KEOGH "I feel better than James Brown" 5 lines 6-AUG-1991 00:01 -------------------------------------------------------------------------------- Welcome to VAX NOTES This conference is for discussions relating to The Information Systems SIG  ================================================================================ Note 2.0 RDB Q & A - SNAPSHOT FILE EXTENDS 1 reply VAXNET::WILMOREA31 17 lines 20-AUG-1991 09:49 -------------------------------------------------------------------------------- RDB Q & A - SNAPSHOT SIZE MANAGEMENT What governs when the RDB Snapshot file extends and how can this be controlled ? Is space within the file re-used as transactions are commited and new ones start ? (Background: we have a number of applications that write data to an RMS file. A single program is run to then load this data into RDB. Thus we only ever have one update process. When this program is run in catch-up mode - ie when a lot of data has been bufferred in the RMS file and needs to be loaded - we are getting many extends of the Snapshot file. On certain occasions the Snapshot file size has become the same as the database size ~50000 blocks. The load program is written in the GEMBASE 4GL. This 4GL uses two processes to attach to the database.) ================================================================================ Note 2.1 RDB Q & A - SNAPSHOT FILE EXTENDS 1 of 1 VAXNET::SMITHI2 "Ian Smith, Rdb/VMS Engineering" 18 lines 20-AUG-1991 17:57 -------------------------------------------------------------------------------- Each SHARED or PROTECTED transaction writes snapshot records to the .SNP file. As each READ ONLY transaction starts it is given a highwater mark transaction id. This limits it's visible data to transactions committed when it started. The .SNP space can not be reused while the READ ONLY user is active. Once commited the space will be reclaimed. Try: EXCLUSIVE transactions (no .SNP file I/O at all) Remove the long running READ ONLY transaction Use the ALTER DATABASE ... SNAPSHOT ALLOCATION command to truncate the .SNP file. Ian  ================================================================================ Note 3.0 Utility access to closed db 1 reply VAXNET::LINTONP12 4 lines 20-AUG-1991 10:11 -------------------------------------------------------------------------------- How do we keep users from accessing an Rdb database but still have utility access? My DBA tells me that one version of Rdb (3.1?) allowed him to close the database for users but still have utility access but this facility is not present under V4.0. ================================================================================ Note 3.1 Utility access to closed db 1 of 1 VAXNET::SMITHI2 "Ian Smith, Rdb/VMS Engineering" 3 lines 20-AUG-1991 17:48 -< soon >- -------------------------------------------------------------------------------- Rdb/VMS V4.1 adds explicit utility access using RMU/OPEN... Ian  ================================================================================ Note 4.0 RDB Q & A - Attach Time 3 replies VAXNET::SCHUBERTM26 5 lines 20-AUG-1991 11:01 -------------------------------------------------------------------------------- Rdb V4.1 makes use of Global Buffers. This will hopefully improve ATTACH time to a database. Is DEC looking to further improve ATTACH time to a database, or is that as good as it will get? If so, what are the future improvements? What are some methods for improving ATTACH time to a database, given V4.1 and prior. ================================================================================ Note 4.1 RDB Q & A - Attach Time 1 of 3 VAXNET::SMITHI2 "Ian Smith, Rdb/VMS Engineering" 14 lines 20-AUG-1991 17:51 -------------------------------------------------------------------------------- In V4.1 we reduced the amount of metadata which needs to be read. Relations like RDB$FIELDS and RDB$FIELD_VERSIONS are now more compact. If you use RMU/OPEN then you save the global section creation time, and only need to map it. Why is this a problem? DO you attach to a lot of databases? Or to the same one many times. Rdb/VMS needs to do quite a lot of setup during ATTACH time. ...and yes we are still investigating ways to reduce this time. Ian ================================================================================ Note 4.2 RDB Q & A - Attach Time 2 of 3 VAXNET::SCHUBERTM26 6 lines 21-AUG-1991 16:42 -< The same database many times >- -------------------------------------------------------------------------------- We use RALLY and attach to the same database many times. For various reasons, our RGAs are kept as small as possible and selection of a most menu options means performing a RALLY RUN which involves attaches to the database. It is nice to know that attach time is being addressed. ================================================================================ Note 4.3 RDB Q & A - Attach Time 3 of 3 TEMBEL::BRADLEYM19 10 lines 22-AUG-1991 12:16 -< Minimise this overhead >- -------------------------------------------------------------------------------- I would suggest that minimising the number of times you attach and detach is still a pretty good idea. Although the attach time is getting better, there will always remain a substantial overhead for attaching to a database, particularly if your apllication is also doing image activation. Cheers, Mark.  ================================================================================ Note 5.0 Rdb conference No replies TEMBEL::KEOGH "I feel better than James Brown" 2 lines 20-AUG-1991 12:24 -------------------------------------------------------------------------------- Due to public demand, there is now a dedicated Rdb conference. Press KP7 to add it to your notebook.  ================================================================================ Note 6.0 RDB Q & A - Joining Databases 1 reply VAXNET::SCHUBERTM26 5 lines 20-AUG-1991 17:06 -------------------------------------------------------------------------------- In order to reduce data duplication it would be nice if tables from different databases could be joined. Basically, the request is for the ability to view multiple databases as 1 single database. Is this something that DEC are looking to move towards? If so, can you give some details. ================================================================================ Note 6.1 RDB Q & A - Joining Databases 1 of 1 VAXNET::SMITHI2 "Ian Smith, Rdb/VMS Engineering" 9 lines 20-AUG-1991 17:52 -------------------------------------------------------------------------------- >Is this something that DEC are looking to move towards? yes. >If so, can you give some details. no Ian  ================================================================================ Note 7.0 Archiving AFILEs 4 replies VAXNET::LINTONP12 5 lines 22-AUG-1991 10:56 -------------------------------------------------------------------------------- If I archive my Rally afiles together with the Rdb databases they use will I be able to run the afiles under much later versions of Rally? I believe that there is a commitment that rmu/backups of Rdb databases will be able to be restored under future versions of Rdb. What about my Rally applications? ================================================================================ Note 7.1 Archiving AFILEs 1 of 4 TEMBEL::BRADLEYM19 14 lines 22-AUG-1991 12:21 -< No guarantees >- -------------------------------------------------------------------------------- I can't answer you question concerning RALLY, but I thought I had better comment on Rdb backup. There is no absolute guarantee that the backup format produced by RMU/BACKUP will be forever readable. We suggest that if you wish to retain a copy of you database that is version independant, you should use the EXPORT command from RDO or SQL$. At the moment, RMU/RESTORE will restore a full and complete database backup created with versions since 3.0. Cheers, Mark. ================================================================================ Note 7.2 Archiving AFILEs 2 of 4 VAXNET::SMITHI2 "Ian Smith, Rdb/VMS Engineering" 10 lines 22-AUG-1991 13:14 -------------------------------------------------------------------------------- Mark, It was I who suggested that RMU/BACKUP's be used. As RMU/BACKUP calls RMU/CONVERT then for the BACKUP (.RBF) files will be useable. There is no intention of changing the format at this time. If you need to archive the data for a long time (>5 years), then I agree with Mark that EXPORT should be used. Ian ================================================================================ Note 7.3 Archiving AFILEs 3 of 4 TEMBEL::LINTONP12 2 lines 23-AUG-1991 08:49 -< What about AFILES? >- -------------------------------------------------------------------------------- Thanks for the Rdb info. But what about AFILEs? The data will be of limited use in 5 years time without the applications. ================================================================================ Note 7.4 Archiving AFILEs 4 of 4 VAXNET::SMITHI2 "Ian Smith, Rdb/VMS Engineering" 8 lines 23-AUG-1991 09:08 -------------------------------------------------------------------------------- Sorry I can't really give a definitive answer concerning the application files. This is something that can be addressed in an INQUIRY SPR to the DEC RALLY group. I'll also pass on your question so that it can be addressed through other channels. Ian