[Glass] extent0.dbf grows

Trussardi Dario Romano via Glass glass at lists.gemtalksystems.com
Fri Jul 31 08:58:42 PDT 2015


James,

> 
>> On Jul 31, 2015, at 3:37 AM, Trussardi Dario Romano via Glass <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

	
> 
>> 	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.

> 
>> 	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 ?
> 
>> 		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.
> 
>> 		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


	

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


More information about the Glass mailing list