hello all:
we have alot of databases and alot of views that are huge up to 255 M ,is this normal? I think not I think there are some tips to minimize the view size ,can any one with expierence in views give some tips?
thanks
Dalia
Subject: Big views are expected …
… in certain circumstances. We tend to start worrying about any that are over 100MB since they tend to cause disk thrashing on even reasonable workstations.
Tip: reduce the number of columns, especially reduce the number of sorted (even optionally sorted) columns
Reduce the size of the fields (lots of long text fields will make the indices grow)
Reduce the number of docs selected by the view
-- for this in hierarchical views there is a trick using @Descendants or something like that, but I forget the details.
Also: try to tweak the view update settings, big views shouldn’t be auto unless they really need to be. (I think)
That’s all I can think of.
=B-)
Subject: Some Views take a huge disk space up to 255 m
Hello,
We got the same problem with one of our customer. There was one application which runs on a R5 Server and a copy (not a replica) of this database on a R6 server.
On the R5 Server the database worked pretty fine. On the R6 Server the database increase in Size by more than 10 times. Eg. R5 1 GB, R6 10 GB.
The only difference what we find out ist the size of the views. The views are so big on the R6 Server.
If you delete the db on the R6 Server and copy it newly on the server, everything looks fine. But after 4 weeks the database has blown up and the work with it was extremly slow.
Does anybody know what happend?
Thank you in advance
Michael
Subject: Most of the trade journals can help you with this…
For example, Advisor, e-Pro, and The View… have all written articles on this. Here are some recent ones you may wish to purchase:
Tune Up Your Views: Streamline view designs to save disk space and improve application performance.
http://lotus.advisor.com/doc/11869
Automate View Analysis: Save disk space and improve performance by streamlining view sizes.