Re: Information store size increases when querying through EXOLEDB

• Previous message: Tom Rizzo [MSFT]: "Re: Event Registration failure"
• In reply to: Tom Rizzo [MSFT]: "Re: Information store size increases when querying through EXOLEDB"
• Messages sorted by: [ date ] [ thread ]

Date: Fri, 25 Feb 2005 07:49:12 -0800

Thanks Tom. Since I posted to the group I've raised a support incident with
MS who've found that, as you suggested, it is the search folders being
created and not reused that is increasing the size.

We're just in the process of trying to work out why they're not reused. If
there's no activity in my database the id doesn't actually change each time
so the search folders created the first time should be reused, but they
aren't being.

Thanks again for your help.

"Tom Rizzo [MSFT]" wrote:

> The only thing I can think of is that we do cache the results of a query (as
> a search folder) so that if you run the same query, it's fast. That could
> explain your 1 meg increases. Since your query is dynamic based on an ID
> that I assume changes, as you run more and more queries, we cache more and
> more until we blow the limit. However, we should stop at 11 cached views.
> Try querying the property
> http://schemas.microsoft.com/mapi/proptag/0xe680003
> which will return back the number of persisted views that we should keep on
> the folder.
>
> One thing you can do is up the diagnostic logging on your server and when
> you run the query, you'll see views being created in the log if this is the
> problem.
>
> Hope this helps!
>
> Tom
>
>
> --
> Looking for a good book on programming Exchange, Outlook, ADSI and
> SharePoint? Check out http://www.microsoft.com/MSPress/books/5517.asp
>
>
>
> "Chris Betterton" <Chris Betterton@discussions.microsoft.com> wrote in
> message news:16B6B847-8E3A-4B8A-8DF3-85E9074DC44F@microsoft.com...
> > I'm developing an application for Exchange 2000 and 2003 using EXOLEDB.
> > This
> > application repeatedly queries the Exchange information store using Web
> > Store
> > SQL, and after doing so around thirty times the size of the web store
> > increases by 1 Meg exactly. The increase in size cannot be explained by
> > increasing mailbox sizes (it's just querying, not doing any updates) and
> > as
> > this application runs as a service on site - and has to run over 300
> > queries
> > - eventually the information store blows the 16GB limit.
> >
> > I've also managed to do something similar using the Exchange Explorer
> > application (ExchExplorer.Exe) from the Exchange SDK. As soon as I click
> > on a
> > user's calendar folder, Exchange Explorer pauses whilst (I assume) it
> > queries
> > that folder, and the exchange store increases in size in the same way.
> >
> > This behaviour is occurring on Exchange 2000 SP3 with the August 2004 post
> > SP3 update rollup installed, and on Exchange 2003 SP1.
> >
> > Extensive searching of the knowledge base and Google has only found this
> > article for Exchange 2000:
> >
> > http://support.microsoft.com/kb/815296
> >
> > which describes a similar problem, although I'm not doing a deep traversal
> > query of a public folder, I'm doing a shallow traversal of a private
> > folder.
> > Installing the August 2004 post SP3 rollup (which supersedes the September
> > 2003 rollup mentioned in the article) doesn't resolve the problem.
> >
> > Any help would be greatly appreciated, as this problem caused a customer's
> > Exchange database to blow the 16GB limit, taking down email for a whole
> > day.
> > The only way to recover was to extract the mailboxes, delete the
> > information
> > store, and exmerge the mailboxes back. I've provided a code sample below.
> >
> > Thanks
> >
> > Chris Betterton
> > Technical Director
> > Isibus Ltd.
> >
> > _Code sample_
> >
> > The application is designed to keep records in an SQL Server database
> > synchronised with appointments in each user's calendar. It retrieves a
> > list
> > of records from the database, and then runs the query to retrieve the
> > matching appointment as an ADO recordset. Here's the relevant code
> > (references to LogMessage are to a procedure that simply writes the
> > message
> > to the event log):
> >
> > Dim sMailBoxURL As String
> > sMailBoxURL = "http://localhost/exchange/" &
> > dtbActivityList.Rows(intCurrentRow)("sys_user") &
> >
> > "/Calendar"
> >
> > objConn.Provider = "ExOLEDB.DataSource"
> > Try
> > objConn.Open(sMailBoxURL)
> >
> > ' Find the existing contact
> > sSQL = "select ""DAV:href"", ""DAV:getlastmodified"",
> > ""urn:schemas:calendar:dtstart"", " & _
> > " ""urn:schemas:calendar:dtend"",
> > ""urn:schemas:calendar:reminderoffset"", " & _
> > " ""urn:schemas:mailheader:subject"",
> > ""iios:calender:chargeable"",
> >
> > ""iios:calender:proleid"" from " & _
> > " SCOPE ('shallow traversal of " & _
> > """" & sMailBoxURL & """')" & _
> > " where ""iios:calender:activityid"" = CAST(""" &
> > intActivityId & """ as ""int"") " & _
> > " and ""iios:calender:proleid"" is not null"
> >
> > objRS.Open(sSQL, objConn)
> > LogMessage("Found a mailbox")
> > Catch e As Exception
> > LogMessage("Couldn't find a mailbox")
> > End Try
> >
> >
> > The same application also (in a completely distinct section of code) does
> > something similar with contacts in a public folder, which DOESN'T cause
> > the
> > problem, even though the volumes are similar:
> >
> > Dim objConn As New ADODB.Connection()
> > Dim sSQL As String
> >
> > Dim objRS As New ADODB.Recordset()
> >
> > Dim sMailBoxURL As String
> > sMailBoxURL = "http://localhost/public/iios contacts/"
> > objConn.Provider = "ExOLEDB.DataSource"
> > objConn.Open(sMailBoxURL)
> >
> > ' Find the existing contact
> > sSQL = "select ""urn:schemas:contacts:customerid"", ""DAV:href""
> > from " & _
> > """" & sMailBoxURL & """" & _
> > " where (""urn:schemas:contacts:customerid"" = '" &
> > intProleId & "')"
> > objRS.Open(sSQL, objConn)
> >
> >
>
>
>

• Previous message: Tom Rizzo [MSFT]: "Re: Event Registration failure"
• In reply to: Tom Rizzo [MSFT]: "Re: Information store size increases when querying through EXOLEDB"
• Messages sorted by: [ date ] [ thread ]