Bases de datos Exchange 2007 crecen muy rapido RRS feed

  • Pregunta

  • Hola,

    Ojala me puedan ayudar con esto:

    Tengo una DB de Exchange que esta creciendo muy rapido, y esta a punto de consumir el espacio total del disco, en el disco solo se encuentra el archivo EDB que pesa 28 GB sin embargo el espacio en disco se esta consumiendo. Alguien sabra por que?
    martes, 17 de noviembre de 2009 18:51


Todas las respuestas

  • Tenes configuradas cuotas en las casillas?
    Pablo Vernocchi
    jueves, 19 de noviembre de 2009 1:32
  • Hola,

    Pregunta, cuantos usuarios tienes, cuales son las cuotas definidas para esos usuarios..

    Por otro lado te paso algunas razones para el crecimiento de las DBs


    Mailbox stores

    1.  The mailbox store size grows rapidly on mailbox servers.
    If a specific mailbox store grows in a quick manner, first check the following information: 
       a.  Are there too many mailboxes on the mailbox store?  
       b.  Are there any big mailboxes?  
       c.  Is the store storage limitation too large? 
    Later, you can use the following commands to check the stores' status: 
       a.  Run “eseutil /g” on the database to check whether it includes unhealthy records.  
       b.  Run "eseutil /ms" to check the free space on the store.  
       c.  Run "isinteg -dump" to dump the Index Age and Folder tables. 
    In addition, check whether the online maintenance for this database successfully finishes(i.e. releases normal free space) every night.

    If all the mailbox stores grow simultaneously, check the overall message volume by using the Performance Monitor.
    To do so: 
       a.  Open the Performance Monitor on the Exchange server.  
       b.  Select “SMTP Server” object in the "Performance object" list.  
       c.  Select the corresponding instance such as “SMTP 1”.  
       d.  In the counters list, select the following counters to monitor: “Messages Received Total”, “Messages Receiver/sec”, “Messages Sent Total”, “Messages Sent/sec”, “Messages Bytes Total”, “Messages Bytes Total/sec” , and anything else you think necessary. We can compare these captured counters' values with the values under the normal conditions. Moreover, a high value also indicates an undesirable situation, such as the counter “Messages Receiver/sec” is near 10. (It depends on the exact environment.)  

    2.  Mailbox store size grows rapidly on the bridgehead servers.

    The bridgehead server may hold a connector or work as an SMTP gateway, so try checking database health first. In addition, because the Exchange server holds messages in a mailbox store, it is wise to check the message volume with PerfMon (SMTP Server object).

    3.  Mailbox store size grows rapidly on Front-end servers.

    A mailbox store for a common Front-end server is not necessary. Therefore, dismount or delete the problematic mailbox store.
    Note: On Front-end servers, public folder stores should be dismounted or deleted as well. 

    Public folder stores

    1.  The public folder store size grows rapidly on public folder servers.
    As for a common public folder server, apart from the general troubleshooting methods, you also need to pay attention to the message volume and database health. Please refer to the sections "General troubleshooting methods" and "Mailbox store" for the troubleshooting information. 
    2.  The public folder store size grows rapidly on application servers.
    It is a common situation for the database to grow rapidly on an application server. The reason is that there are lots of temporary tables and system tables created for Category, Search, Index and so on. These tables will not be cleaned immediately. Instead, they will be cleaned 40 days later, which is by design. 


    Everything that you can do for TROUBLESHOOTING this issue. 
    Transaction log files are growing rapidly on your exchange server. It could be either of the two below reasons:

    1. SMTP issues
    2. Store issues

    If the issue is that only the Logs are growing then the first thing we can do to analyze this issue is to stop the SMTP service and check whether the logs are still growing or not. If it still grows then it is not certainly a SMTP issue. It can be a store issue.

    Possible SMTP Issues                                     Possible STORE Issues
    1. NDR Looping                                                1. Corrupt mail stuck in the queue
    2. Spamming                                                    2. 3rd party software accessing a particular mailbox
    3. Increased mail flow                

    Major causes of fast growing logs and how to handle them:

    1. Looping Messages
    2. Public Folder Replication
    3. Open Relay
    4. M: drive or IFS file level Antivirus scanning
    5. Macintosh Entourage clients resend bug
    6. Exmerge/Move Mailbox operations
    7. Mailboxes with unusually high activity
    8. Online Maintenance

    Let’s discuss all the above mentioned topics we use for troubleshooting.


    If there is a specific rule or rules that is getting fired very often and repeatedly, this could possibly lead to the problem as to why email is bouncing.
    Increase the diagnostics logging for Rules for both Mailbox and Public folder for MSExchangeIS.
    Look at the message tracking log on your server. You will find this only if the message tracking is enabled.
    Info on the Message tracking logs:
    • Default Location: <DRIVE:>\Program Files\Exchsrvr\<servername>.log
    • Format: <YEAR><MONTH><DAY>.log
    • On clustered servers: \\<Exchange Virtual Server name>\<servername>.log

    We can perform three operations using these Message tracking logs:

    1.1  Looking for Loops
    1.2  Looking for top recipients
    1.3  Looking for possible large incoming spam volume

    1.1 Looking for Loops:

    Tools to use: “loopdetect.exe” or “msgtrack- loopdetect.exe”
    Command line: loopdetect.exe <tracking log> >c:\loopoutput.txt
    Output: Interpret the output and you know what to do next.

    1.2 Looking for Top recipients:

    Tools to use: "msgtrack-recipcount.exe" and "recipcount.exe"
    Command line: recipcount.exe <name of the tracking log> >c:\recipoutput.txt
    Output: This will create the "recipoutput.txt" which should then be looked into. This will essentially give you a list of mailboxes that have received mail since the tracking log has started and will list the recipients by the number of emails that they got. So - the busiest recipients will be at the top. You can then compare the numbers and see if there are large discrepancies in numbers, and if so - this is something that is worth looking into.

    NOTE: if you see the "<SERVERNAME>-IS@DOMAIN.COM" as one of the top recipients, that means that the server is getting a lot of public folder replication messages!

    1.3  Looking for possible large incoming spam volume

    Tools to use: "spamcount.exe"
    Command line: spamcount.exe <name of the tracking log> >c:\spamoutput.txt
    Output:  This tool returns the list of most frequent senders. So - if someone is sending a lot of email to our mailboxes - he will be listed on the list - again, something to look into.
    You can use the "aqadmcli" utility to delete all messages sent by a specific user, say postmaster@domainA.com.
    To delete all messages sent by a specific user, say postmaster@domainA.com from all queues, use the following command line:
    aqadmcli "delmsg flags=SENDER,sender=postmaster@domainA.com"
    aqadmcli "msgaction ma=DEL,flags=SENDER,sender=postmaster@domainA.com"

    Unsolicited commercial e-mail (UCE)
    UCE, also known as spam may cause this issue. To troubleshoot this issue, perform the following actions:
    • Determine whether the server is acting as an open relay.
    • Collect the message tracking log, and then use the Spamcount.exe program to determine whether a spam attack is occurring.


    Public folder replication can obviously be a big generator of transaction logs. In most cases, this shows up as a problem in larger environments, where administrators might not be aware that someone else has created a replica for certain public folders on some other servers. The symptoms are that the transaction logs are growing and the size of the public folder store is growing too.
    Note here though that - because of the fact that a public folder store might have a lot of white space in it, the actual size of the PF store databases might not be increasing for some time even though the store holds more and more content.
    If there are questions if public folder store is a recipient of messages that are then causing transaction logs to be created - there are 2 things to check:
    1. The message tracking log file - check the "top recipients" and see if "<SERVERNAME>-IS@DOMAIN.COM" is one of the tip recipients. This is the default SMTP address of the MAPI public folder store on Exchange 200x servers. Seeing that the public folder replication messages are sent from store to store, it will be this address, rather than individual public folder addresses, that will receive replication messages.
    For steps on checking the message tracking log, please see the "Looking for 'top recipients'" in this Bulletin.
    2. We can turn on diagnostics logging on the public folder replication messages to see if the server is getting hammered with those. To do so, go to the server object in ESM, and on Diagnostics Logging, turn up logging on:
    MSExchangeIS > Public Folder > Replication Incoming Messages (set it to Max)
    If the server is getting a lot of public folder replication messages, you will see a lot of events with event IDs of 3028 and 3030 (those will be the most common ones).
    NOTE: If the customer does realize here that some PF replication was triggered that should not have been triggered - they should just remove the replicas that they want to remove. They should NOT under any circumstances go and delete PF replication messages from queues, as that just causes problems later. They can alternatively create separate connectors for system messages only and then schedule them to give their "normal" mailflow more room to breathe.

    03. OPEN RELAY

    If the server is an open relay, there will be tons of transaction logs. You will also usually see a bunch of items in the BADMAIL folder. The key here is of course, locking the server down so it is not an open relay anymore. There are several articles that talk about how to work on that, so - I will not go into details on this Bulletin.
     Huge amount of email in BADMAIL though is an indication of possible problems. Do note though that especially with Exchange 2003 SP1 changes, it is possible to configure the badmail directory to be emptied on a schedule, so that should be taken into the consideration too.


    Scanning the M: drive / Exchange IFS will definitely cause the transaction logs to show up. File-level AV scanners in most cases modify the item that they touch. Seeing that the M: drive is a virtual representation of your databases, those modifications are made to the database data. Therefore - there will be tons of transaction logs, usually generated over short period of time (during the duration of the scan). Databases will typically not increase in size as a result.
    You will usually be able to see events in the Application log that give you clues that the M: drive / IFS are being scanned.
    The following are the events that could get logged if the M: drive is exposed and scanned:
    Event: ID 6 
    Event ID: 2045
    Needless to say, file level scanning needs to be stopped as soon as possible!


    If a user in Entourage attempts to send an email that is larger than the mailbox send policy allows, the message hangs in the Outbox and the transaction log files on the Exchange server grow at an alarming rate, until the admins physically go to the user and delete the item out of the Outbox.
    Essentially - what happens is that the Entourage client retries to send a message to the server over and over, therefore causing a ton of transaction logs on the server. You will usually not see the database size increase with this problem.
     This problem happens on Exchange 2003 SP1 servers and Exchange 2000 SP3+ servers. To fix this, upgrade to the latest service packs or identify the clients and delete messages stuck in the outbox.
    Check to see if any Entourage clients are contributing to this issue:
    If the Entrourage client is the issue, you'll have the information in the logs to indicate which client is the offending client.
    1. Obtain the IIS logs from the server for that particular time frame.
    •          E2K3 - The default path is C:\WINDOWS\system32\LogFiles\W3SCV1
    •          E2K   - The default path is C:\WINNT\system32\LogFiles\W3SCV1
    2. From the folder where the logs in question are in, run the following command:
    FOR %A IN (*.log) DO FIND /i "DavMailSubmissionURI" %A > %A_mailsubmit.log
    3. Review the output files and look for one or more clients repeatedly doing this command (every couple of minutes or more frequently)
    4. If found, locate those Entourage clients and remove the offending message from the user’s outbox.
    On the Entourage client, the workaround is just click to clear the Send and Receive All check box.
    To do this, follow these steps:
    --> On the Tools menu in Entourage, click Schedules.
    --> Click to clear the Send and Receive All check box.


    For 1 GB of data that you move, an additional 1 GB of transaction logs is generated at the source and target server. When you move mailboxes from source server to target server and forgot to enable circular logging, all of the mailbox messages are ultimately created on the target server and deleted on the source server. Both creations and deletions are also logged transactions. Large amount of move mailbox operations will cause a lot of transaction logs on both servers - the server that the mailboxes are being moved from and the server that the mailboxes are being moved to. This needs to be checked as well when you face an issue of increased transaction logs.
    Additionally, certain Exmerge operations will create a lot of transaction logs too. Example would be archiving of email into PST files (which deletes the messages from the store) or importing messages from PST files into the store (which creates messages in the IS).
    Merging mailboxes using the Exchange 2003 SP1 Recovery Storage Group functionality will also create transaction files.


    "The Total Ops will list a numeric value of the total number of operations the server has processed for the each user within the last minute. This value should not be "Constantly" above 200 when refreshing the screen."
    1. Expand "Servers", expand your Exchange computer, expand "First Storage Group", and then expand "Mailbox Store".
    2. Click "Logons", click the "View" menu, and then click "Choose Columns".
    3. In the "Modify Columns" dialog box, click "Total Ops", click "Add".
    4. Also Add "Open Messages","Open Folders","Open Attachments" and click "OK".
    5. Click "Logons", click the "Action" menu, click "Export List..." and in the Save As dialog box, name the file the name of the Mailbox Store and in the "Save as type:" box select "Text (Comma Delimited)(*.csv) and save the file.
    6. Repeat this process for each Mailbox Store.
    Output: Mailboxes that have Total Ops with sustained values, (for several minutes), in excess of 300 should be investigated to determine their ADD-Ins. In addition, mailboxes that have greater than 30 open messages should be investigated to determine their Add-Ins as well. Once a mailbox has been identified then remove the Add-Ins one at a time to determine which Add-In is causing the high Total Ops or high Open Messages count.


    You may experience the size of the messaging database increasing unexpectedly when a messaging database (MD on your server contains items that were not successfully deleted.  Seeing that online maintenance performs a series of actions on the data within the Exchange database - some of online maintenance tasks will also generate transaction logs on the server. This will typically be only during the online maintenance period though, but it is a good thing to keep this in mind as one of things that cause log file creation.

    jueves, 19 de noviembre de 2009 4:27
  • Tengo en esa BD alrededor de 250 usuarios, con limites como sigue:
    -Issue warning 40 mb
    -Prohibit send 45 mb
    -Prohibit send and receive 50 mb

    jueves, 19 de noviembre de 2009 16:38
  • Esa base podría crecer hasta los 20 GB aproximadamente... dependiendo de algunas configuraciones como por ejemplo el deleted item retention y el deleted mailbox retention.
    Pablo Vernocchi
    jueves, 19 de noviembre de 2009 19:00
  • Pues en los paramentros que mencionas se tiene configurado:

    deleted item retention: 7 days 
    deleted mailbox retention: 30 dias

    Pero aun asi sigue creciendo, poco pero sigue creciendo, eso es normal en las bases de datos de exchange?
    viernes, 20 de noviembre de 2009 18:33
  • Si, en la medida que los usuarios vayan recibiendo correos, y que vayan guardando info en Exchange... Es un comportamiento normal. Siempre van a crecer hasta llegar a un tamaño máximo definido por varios parámetros:

    Pablo Vernocchi
    viernes, 20 de noviembre de 2009 20:00
  • Gracias Pablo,

    Entonces apesar de tener los parametros:

    -Issue warning 40 mb
    -Prohibit send 45 mb
    -Prohibit send and receive 50 mb
    -deleted item retention: 7 days 
    -deleted mailbox retention: 30 dias

    la DB de datos siempre va a seguir creciendo hasta llegar al maximo indicado en Database Size Limit in GB. Que pasa cuando la BD llega a su limite?

    Y gracias por el link de tu articulo, pero no lo pude leer en tu bloc ya que me no encuentra la pagina.

    lunes, 23 de noviembre de 2009 16:38
  • Hola Gabriel,

    Lo que quiere decir es que la base va a crecer una cierta cantidad de espacio y luego va a dejar de crecer, o porque se empieza a usar el espacio en blanco o porque la cuota de los usuarios llega a su máximo y no podrán crear objetos nuevos.

    Pablo Vernocchi
    lunes, 23 de noviembre de 2009 22:52
  • Ha ok, entonces esto quiere decir que colocando el limite de la BD, no creceran más alla y cuando llegue a este limite no se podran agragar más mailbox
    martes, 24 de noviembre de 2009 2:15