1 2 Previous Next 11 Replies Latest reply on Apr 19, 2011 4:45 AM by marklenders

    EPODataChannelData table is 47Gb


      Hi All,


      I have a case with McAfee, but while I am waiting for a reply I thought I would put this question forth. Is there a reason why my EPODataChannelData table is 47Gb in size? Is this normal?


      A few weeks ago the entire DB size was only 6Gb or so (2400 nodes)


      ePO Version 4.5 P3 HF1

      VSE 8.7 P3

      EEPC v6.0.1 (with new 6.0.2 extensions)

      DLP v9

      MA4.5 P1



        • 1. Re: EPODataChannelData table is 47Gb

          Hi, Mark, I have the same problem with the table (with very few rows)


          Did you solve it?

          • 2. Re: EPODataChannelData table is 47Gb

            It's been ongoing, I have been working with tier 3 for quite sometime. I would suggest you contact McAfee about this issue, the fix isn't something I would recommend doing on your own.


            We basically had to delete and recreate the EPODataChannelData table to clear up the space once again. However it would continue to grow overtime, at one point reaching 150Gb! Each time it got out of hand we recreated the table. There is some diagnostics we were going to try however I couldn't leave the DB where it was I had to get it off of the shared server so it wouldn't impact itself or any other DBs.


            I ended up moving the DB from a remote SQL box to a local SQL server on the ePO server and since then the size increase has been minimal, maybe 1gb over a week, which may not indicate a fix but its less than what it was doing before.


            Let me know if you have any other questions so i can pass along what i know, in hopes that you can solve your issue.



            • 3. Re: EPODataChannelData table is 47Gb

              I'm already speaking with support, for the moment they are telling me to install HF1 to solve this problem. But you already have the HF1 installed before having this problem?


              very important to me is to know if this table contains important data (computer cipher keys?) or not.


              Lots of thanks you your answer

              • 4. Re: EPODataChannelData table is 47Gb



                did you have an answer from the support? I have the same problem, my table EpoDataChannelData is 50 GB big and growing. I've opened a ticket with support but they've only replied with instructions on how to purge events and other stuff.

                The table has only about 250 rows, do you know what's containing and how to shrink it?

                I have epo 4.5.0 patch 4



                • 5. Re: EPODataChannelData table is 47Gb
                  Sailendra Pamidi

                  hi there,

                    What version and service pack of SQL are you using? This may be triggered by a known MS issue for which they have hotfixes.


                  FIX: LOB pages that are allocated in a failed INSERT statement may not be reclaimed after you apply SQL Server 2005 SP3, SQL Server 2005 SP4, SQL Server 2008 SP1 or SQL Server 2008 R2


                  • 6. Re: EPODataChannelData table is 47Gb

                    Hi, Mark, the answer from support was, restart the server (the sql server) and it runs !

                    • 7. Re: EPODataChannelData table is 47Gb

                      Thanks Sailendra, I have sql 2005 SP2, that article is related to SP3 and SP4 and it's not clear about SP2.


                      Thanks Nitro, so you restared the server and the table went back to normal size? Sorry for asking again, but restarting that SQL server is quite hard because we have many databases there, so I'd like to be sure that it worths it.

                      • 8. Re: EPODataChannelData table is 47Gb

                        Hi, Mark, I'm not (I don't remember) sure if the database size returns to normal or do tou will need to truncate this table, but I'm sure that the table stops growing.

                        • 9. Re: EPODataChannelData table is 47Gb

                          I know it's a pain but rebooting the Sql server should indeed resolve the problem (but not the root cause, so I guess there is a risk it may still return at some point).

                          i'd still say it's worth scheduling a reboot though.


                          You do not need to truncate the table.


                          Note that it's normal for this table to very in size (bigger and smaller) when it's running properly. Think of it as a cache for the DataChannel.





                          1 2 Previous Next