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

Conference orarep::nomahs::dec_data_distributor

Title:	The Replication Option for Rdb
Notice:	Product renamed to Replication Option for Rdb
Moderator:	BROKE::PROTEAU

Created:	Wed Mar 02 1994
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	287
Total number of notes:	1231

235.0. "About data storing on RDB$CHANGES" by itvms1.it.oracle.com::ITOTA () Wed Jul 31 1996 12:08

	Hi,

	another "strange" situation:

	customer defined a table with a text field with datatype
	varchar (32000)! ( I didn't design db and replication
	strategy).

	135 records had been stored on that table.

	I read rdb$changes fields datatype and modification field
	is varchar(10000).

	After record storing, we found about 4800 records on rdb$changes,
	related to 135 original records.

	It seems that about 1 original record had been splitted in 
	35 on rdb$changes ( the first 4 - 5 full and the other 30 empty
	{or maybe with blanks}).

	So it seems to use only 600 compressed bytes per rdb$changes record 
	and to compress the whole field . Maybe?

	So our questions are:

	a)	why it uses only part of the record on rdb$changes also if
		space needed to store a record modification is larger?

	b)	suppose a varchar(32000) field with only 1000 byte used.
		In which way it stores in rdb$changes a varchar(32000)
		field ?


			Thanks a lot another time,


						Ivo Tota

T.R Title User Personal
Name Date Lines

235.1 NOVA::SMITHI Don't understate or underestimate Rdb! Wed Jul 31 1996 13:17 23

T.R	Title	User	Personal Name	Date	Lines
235.1		NOVA::SMITHI	Don't understate or underestimate Rdb!	`Wed Jul 31 1996 13:17`	23
	~ a) why it uses only part of the record on rdb$changes also if ~ space needed to store a record modification is larger? To avoid fragmentation the algorithm only uses enough of the RDB$CHANGES record to fill a single page. If you use a larger page size you will see more written per RDB$CHANGES row. For instance you could RMU/RESTORE the RDB$SYSTEM storage area with a larger page size. In Rdb7 you can place RDB$CHANGES in its own storage area so then you can easily size the area to better manage RDB$CHANGES. ~ b) suppose a varchar(32000) field with only 1000 byte used. ~ In which way it stores in rdb$changes a varchar(32000) ~ field ? I am not sure exactly what you are asking. A VARCHAR(32000) is really 32002 bytes long. There is no compression done today to store only the "used" portion. What is currently done is to treat VARCHAR(n) as we would a SMALLINT and a CHAR(n). i.e. there is no connection made between the length and data portions. I hope this helps. Ian

~	a)	why it uses only part of the record on rdb$changes also if
~		space needed to store a record modification is larger?

To avoid fragmentation the algorithm only uses enough of the RDB$CHANGES
record to fill a single page.  If you use a larger page size you will see more
written per RDB$CHANGES row.  For instance you could RMU/RESTORE the
RDB$SYSTEM storage area with a larger page size. In Rdb7 you can place
RDB$CHANGES in its own storage area so then you can easily size the area to
better manage RDB$CHANGES.

~	b)	suppose a varchar(32000) field with only 1000 byte used.
~		In which way it stores in rdb$changes a varchar(32000)
~		field ?

I am not sure exactly what you are asking.  A VARCHAR(32000) is really 32002
bytes long.  There is no compression done today to store only the "used"
portion.  What is currently done is to treat VARCHAR(n) as we would a SMALLINT
and a CHAR(n).  i.e. there is no connection made between the length and data
portions.

I hope this helps.

Ian