[Glass] extent0.dbf grows

[James Foster via Glass]

> On Jul 31, 2015, at 8:58 AM, Trussardi Dario Romano via Glass <glass at lists.gemtalksystems.com> wrote:
> 
> James,
> 
>> 
>>> On Jul 31, 2015, at 3:37 AM, Trussardi Dario Romano via Glass <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>> wrote:
>>> 
>>> Ciao,
>>> 
>>> 	i have a deployment system based on GemStone version '3.1.0.6'
>>> 
>>> 
>>> 	Now i use Gemtools and todeClient to do some works on the repository:  update code,  save repository .....
>>> 
>>> 
>>> 	When i login with the tools  i note the repository grows significantly,	  and also,	 the relative  full backups grows significantly.
>>> 
>>> 	To reset the system i need to clear the Object Log with the relative clear command  ( ol clear	 in tode ) 
>> 
>> Do you think that the Object Log grows significantly during your time logged in with the tools? What is its size at the beginning and end of your session?
> 
> 	I don't have real data about the extent0.dbf change size from beginning and end of a gemtools session.
> 
> 	But the full backup size  before Object Log  clear is :	 4 258 529280
> 
> 						after Object Log clear is:		1 376 124 928
> 
> 	
> 	The SystemRepository freeSpace size before Object Log clear is : 	1 092 419 584
> 
> 						after Object Log clear ( and one hour  of system background works )  is:  5 267 701 760

This tells me that your ObjectLog is large and when you clear it you get back a lot of space. No surprise there! So why is the ObjectLog large? What are the entries in the log? Are there a lot of errors? You said, "When i login with the tools  i note the repository grows significantly.” If you don’t "login with the tools" does the repository still grow? Do you think that your login is contributing to growth of the ObjectLog? If so, what are the entries in the log and why are they there?

>> 
>>> 	After 1 hour ,  because i have active the #WAGemStoneMaintenanceTask 
>>> 
>>> 		A) the system 	recovers the free space
>>> 
>>> 		B) the relative full backups become small
>>> 
>>> 	But now i have an extent0.dbf   of   5 991 563 264  	with a freeSpace of 5 267 701 760.
>>> 
>>> 	It is not a very good situation.
>> 
>> Why? Having empty space in the repository (extents) isn’t really much worse than having empty (unused) space in the file system. 
> 
> 	Yes, but if i do copy of extent0.dbf  the relative size is significant.

True. Do you need to make copies of the extent? If so, then shrinking it is certainly helpful.

> 
>> 
>>> 	Questions:
>>> 
>>> 		1) what should I do with the tools to not increase the size of the relative extent ?
>>> 
>>> 			I need to operate with the tools  when the seasideGems30 are down ?
>> 
>> The most common cause of unexpected repository growth is a commit record (CR) backlog. If you log in a session and do not commit while other sessions do commits, then you get a CR backlog. You should ensure that each login, including tools, does a regular commit.
> 
> 	When i works with Gemtools i don't do regular 	commit or abort .
> 
> 	Is't  a wrong practice?
> 
> 	After any command into Gemtools workspace is good practice do a commit or abort command ?

As I said above, you should ensure that each login, including tools, does a regular commit. I’ll let those with more experience with GemTools explain how to do it (I use Topaz and Jade). If nothing else, execute ‘System commitTransaction’ and ensure that you get back ‘true’ as the result.

>> 
>>> 		2) to resize the extent i need to do a full backup and restoring into a virgin extent?
>> 
>> Yes. See https://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-SysAdmin-3.2/GS64-SysAdmin-3.2.htm?https://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-SysAdmin-3.2/7-RepositorySpace.htm#pgfId-82473 <https://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-SysAdmin-3.2/GS64-SysAdmin-3.2.htm?https://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-SysAdmin-3.2/7-RepositorySpace.htm#pgfId-82473>.
>> 
>>> 		3) there is possibility of directly reducing the extent file ?
>> 
>> Repository>>#’shrinkExtents’ might be worth a try, but it is so rarely useful that it has been deprecated.
>> 
>>> 	Thanks for any considerations,
>>> 
>>> 
>>> 		Dario
>> 
>> James
> 
> 	Thanks,
> 
> 		Dario

James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150731/7f5dcf11/attachment-0001.html>