<<< TEMBEL::OFFICE$DISK:[NOTES$LIBRARY]RDB.NOTE;1 >>> -< Rdb >- ================================================================================ Note 1.0 Welcome No replies TEMBEL::KEOGH "I feel better than James Brown" 2 lines 20-AUG-1991 12:18 -------------------------------------------------------------------------------- This conference is for discussion related to Rdb, Digital's relational database system.  ================================================================================ Note 2.0 RDB License Changes With V4.1 2 replies VAXNET::WILMOREA31 3 lines 22-AUG-1991 11:59 -------------------------------------------------------------------------------- It was indicated that when V4.1 of RDB arrives some of the SQL functionality will go into the runtime license. Can you please indicate what functions will be available in the runtime kit and which will not. ================================================================================ Note 2.1 RDB License Changes With V4.1 1 of 2 TEMBEL::BRADLEYM19 9 lines 22-AUG-1991 12:23 -< Same as current RTO RDO >- -------------------------------------------------------------------------------- With version 4.1, interactive SQL will be available with the runtime licence. Functionality available will be restricted to that currently avalable with RDO under V4.0 run time only. This is, all data manipulation, and IMPORT/EXPORT. Cheers, Mark. ================================================================================ Note 2.2 RDB License Changes With V4.1 2 of 2 VAXNET::SMITHI2 "Ian Smith, Rdb/VMS Engineering" 7 lines 22-AUG-1991 13:15 -------------------------------------------------------------------------------- RTO means no CREATE or ALTER commands function, you need an INTERACTIVE or DEVOPMENT kit for these functions. Naturally, you could write your own tool to do this and compile it under the development licence. It will run on the RTO system. Ian  ================================================================================ Note 3.0 Rally & Rdb 1 reply TEMBEL::SCHUBERTM26 2 lines 22-AUG-1991 12:10 -------------------------------------------------------------------------------- How does RALLY interact with RDB? ie. How does it talk to RDB? BLR, call routines? ================================================================================ Note 3.1 Rally & Rdb 1 of 1 TEMBEL::BRADLEYM19 6 lines 22-AUG-1991 12:25 -< DSRI >- -------------------------------------------------------------------------------- Currently RALLY generates it's own BLR and accesses the DSRI interface directly. Cheers, Mark.  ================================================================================ Note 4.0 Rdb Tuning 1 reply TEMBEL::SCHUBERTM26 5 lines 22-AUG-1991 12:14 -------------------------------------------------------------------------------- A DECUS session detailing guidelines for tuning existing Rdb databases would be useful. Nice to see DEC have finally put a section on this (albeit small) in their Rdb documentation with V4.0. ================================================================================ Note 4.1 Rdb Tuning 1 of 1 TEMBEL::BRADLEYM19 5 lines 22-AUG-1991 12:28 -< I thought there was one? >- -------------------------------------------------------------------------------- I believe Georges Cascales did a session on Rdb tuning. Cheers, Mark.  ================================================================================ Note 5.0 More license questions 2 replies VAXNET::WILMOREA31 15 lines 22-AUG-1991 13:37 -------------------------------------------------------------------------------- A few further questions with regard to the new RTO license under V4.1. You indicate that the alter/create functions will not be available in the RTO kit. Does this include physical storage/engineering functions (such as alter schema snapshot allocation... , alter schema journal is etc) as well as metadata definition functions ? (We have a situation where we are using the GEMBASE 4GL on top of RDB. This provides full metadata definitions functionality - such as create table, create field etc) but no facilities to manipulate physical database structure. Thus we are interested to see if the RTO kit will give us the ability to do our physical restructuring - such as create of logical areas etc - or do we need the full kit.) Does RDBexpert require a particular RDB license ? ================================================================================ Note 5.1 More license questions 1 of 2 VAXNET::SMITHI2 "Ian Smith, Rdb/VMS Engineering" 12 lines 23-AUG-1991 08:49 -< RTO might be OK >- -------------------------------------------------------------------------------- From memory I believe it's only the object creation commands which are restricted. Not having a kit here I can't tell you for sure, I suggest you contact your local support people and ask. As I mentioned before SQL compiled code (including dynamic allows these functions, so maybe you can package up a simple program to do what you want. I believe RdbExpert will use any Rdb license, it uses SQL as it's interface language. Ian ================================================================================ Note 5.2 More license questions 2 of 2 TEMBEL::BRADLEYM19 7 lines 23-AUG-1991 09:41 -< Appendix to RDO manual >- -------------------------------------------------------------------------------- There is an appendix to the RDO/RMU reference manual which describes the RTO functionality of RDO. You can be assured that exactly the same functionality will be avaiable in the SQL RTO interface. Cheers, Mark.  ================================================================================ Note 6.0 DEBUG FLAG DISPLAY 1 reply VAXNET::WILMOREA31 8 lines 22-AUG-1991 13:46 -------------------------------------------------------------------------------- Debug flags output is sometimes difficult to see or disappears before it can be read (especially with screen based applications). It can be sent to a file but then (especially when walking through in DEBUG) it cannot be seen which output refers to what code. Is there any way on a windowing terminal (or on two terminals running seperate sessions) to see the output on a window/screen seperate from the application ? ================================================================================ Note 6.1 DEBUG FLAG DISPLAY 1 of 1 VAXNET::GARNERR30 "Whale Oil Beef Hooked" 4 lines 22-AUG-1991 14:58 -< It should be possible ... >- -------------------------------------------------------------------------------- I would think that if you have SHARE privilege, or OPER so you can change protection on your TT device, that you can send the output to a DECterm or a spare VT. Since I have neither on this system, I can't test it, but I would be surprised to the point of putting in an SPR if it didn't work.  ================================================================================ Note 7.0 Maintenance of CDD RDB database 1 reply VAXNET::WILMOREA31 10 lines 22-AUG-1991 13:50 -------------------------------------------------------------------------------- CDD uses an RDB database as its repository. Should this be maintained through normal RMU/SQL commands or are there specific CDD commands for this ? For example we have a CDD database that has extended a number of times. Can we safely resize it through export/import ? Should we be backing up our CDD database using RMU/BACKUP ? I find the documentation unclear on these issues. ================================================================================ Note 7.1 Maintenance of CDD RDB database 1 of 1 VAXNET::SMITHI2 "Ian Smith, Rdb/VMS Engineering" 13 lines 23-AUG-1991 08:57 -------------------------------------------------------------------------------- CDD uses Rdb/VMS is some special ways, using IMPORT and EXPORTY is not advised. Some hooks were provided especially for CDD/Repository but are not currently used by that product, but will be in the future. In a future version CDD will provide it's own interface for exporting and importing. You should be using RMU/BACKUP, unless you can guarantee that noone is using the dictionary at the time. Any and all .RDB databases should be backed up using RMU/BACKUP, there is no other guaranteed facility which understands Rdb structure and transaction semantics... I'll take the message back that the documentation is unclear. Thanks. Ian  ================================================================================ Note 8.0 OPEN/CLOSE and MANUAL/AUTOMATIC No replies VAXNET::WILMOREA31 11 lines 22-AUG-1991 17:03 -------------------------------------------------------------------------------- Just to clarify my comments on open/close and manual/automatic. It seems (especially with the advent of global buffers) that there are advantages to keeping a database open as long as possible even if no users are attached. Thus a "close manual" is needed. However to avoid the neccessity for writing specific startup code (that usually does not work at 1AM after a system re-boot over the weekend) to RMU/OPEN the database would still be nice to have an open automatic. This it would be useful to specify the two options seperately.  ================================================================================ Note 9.0 Attach performance No replies VAXNET::SLACKT30 23 lines 23-AUG-1991 12:42 -------------------------------------------------------------------------------- Attach performance IS a major issue. In our system there are more than 1000 attaches daily on our main production database, and this is after considerable effort to reduce the number of attaches. On to of this, CDD has a well-known reputation of performing abysmally, and one of the reasons for this is generally CDD requires an attach for every job that accesses it. At times CDD is deliberately bypassed because of the delays caused. It is not only the attach itself that is the issue, but the fact that the database query must be compiled into BLR the first time an RSE is encountered within an attach. It is my suspicion that we could recover 20-30% of our system resources if the attach problem/initial optimisation problem went away. We have our metadata area on a disk-shadowed in-memory RAM disk, and average 70 i/o's a second on this (all reads). In my view 95% of these should not be necessary. If other database systems can do it, why not RDB? Tim Slack