[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_60

Title:	Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:	RDB_60 is archived, please use RDB_70..
Moderator:	NOVA::SMITHISON

Created:	Fri Mar 18 1994
Last Modified:	Thu May 29 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5118
Total number of notes:	28246

5066.0. "Snapshot files growing out of control" by 10245::COBROWN (Colin from Danmark) Mon Feb 24 1997 10:35

    Rdb 7.0-00 OpenVMS 6.2
    Applications mostly Rally.
    
    Site is experiencing incredable snapshot file growth, even on storage
    areas that are only read.
    
    Customer logs all his users off at 23:30 each night so we know there
    are no users hanging arround forever. When he checks the database he
    can see that although the snapshot files are growing there are no
    update users in his database.
    
    His snapshot files are currently 4 times his database size (450 MB).
    
    I cannot find anything in notes. Is this possibly been notice someplace
    else?
    
    Colin - Danmark

T.R	Title	User	Personal Name	Date	Lines
5066.1		HOTRDB::LASTOVICA	Is it possible to be totally partial?	`Mon Feb 24 1997 10:39`	6
	since only a RW user can write to the snapshot files, once would have to assume that perhaps the customer is a little confused. How about this, the next time the users are removed from the database, truncate all the snaps down to nothing. Then, the next day, run RMU/SHO STAT and look at the stall messages screen. Look for any processes stalled 'writing' anything.
5066.2		HOTRDB::PMEAD	Paul, [email protected], 719-577-8032	`Mon Feb 24 1997 11:30`	3
	If the areas are truly "read only" then why not set them to "READ ONLY". Then, when their applications all blow up, they will find out which ones are writing to those areas.
5066.3	...and the snapshots keep on growing	10245::COBROWN	Colin from Danmark	`Mon Mar 03 1997 05:15`	20
	CT has been truncating snapshot files when database is taken off line every night. Monitoring the stalls waiting for writing shows that only two applications that are expected to do updates are in fact doing so and their transactions are short. Monitoring, according to the CT, does not show any long running read transactions. Observing the two write applications, reveals that each time they start a new transaction they need to extend the snapshot files. It appears as if snapshot space is never released and reused. This problem seems to have started with version 7.0-00. A second production system at this CT is also showing increased snapshot growth since 7.0-00 was introduced, but it is not so extreme. (This reply has had to be reentered, as thursdays update got lost in the move.) Colin
5066.4	Seems there WAS an active process.	10245::COBROWN	Colin from Danmark	`Wed Mar 12 1997 10:49`	12
	Just to close this the customer had a SQL/services executor hanging arround with a prestarted transaction. When we set the min executors to 0 and idle time out to 300 seconds the problem mostly went away. They still have snapshot growth on the RDB$SYSTEM and no tables in there. At least if I can trust them this time:-) Colin
5066.5		HOTRDB::PMEAD	Paul, [email protected], 719-577-8032	`Wed Mar 12 1997 11:19`	6
	> They still have snapshot growth on the RDB$SYSTEM and no tables in > there. They can disable cardinality updates if they would like (after understanding all of the side-effects that can cause). That should prevent snapshot growth on the system area.