This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Transaction Log Filling up drive

I have been having issues with transaction logs grows and  filling up my drive, this began around the time of upgrading to NPM 11.5 and SAM 6.2. We also integrated the SRM module at the same time. So it could be any one of these components, or maybe when all three get together they like to party?

Has anyone else experienced this?

  • fcpsolaradmin
    After we upgraded to NPM 11.5 RC1, we ran into some issues that required some lengthy support sessions. During those sessions, support saw our log, at 40+gig, and said something was wrong, and that was way too much. (our database was already set to simple, and we had not noticed it, nor really had any issues prior)  After some time, and a bunch of troubleshooting, it seems that our NTA module was the one causing it. I had actually turned off NTA after that, as we were still trouble shooting some other issues, and had it turned off for a week or two.  During that time, our log file never grew past 2 gig. I turned NTA back on last week, and sure enough, the next day our log file was 20+ gig.  I know you did not mention anything about NTA, however, I figured I would share my findings with you just the same.

    Please post and let us know what you find.

    -Will

  • I did not mention NTA but I do have it installed, so I am going to guess our issues are the same. So, as of right now you have a open ticket with support?

    Our recovery model is set to full. But from what  you said that doesn't really have any impact on this issue.

  • I do have a couple of tickets open, however, nothing specifically for the overweight log file yet/again.  We actually had to roll our NPM back to 11.0.1, for the time being, and I, yet again, had to turn off NTA this morning.  We were seeing a large increase in page time outs. I setup a test server with SAM installed, and pointed it over to our swdb server to check it out.  I have had SAM collecting data for several days now, and NTA is all over the SAM reports, with nice, red coloring... so my boss said to shutdown NTA for now.  In our case, NTA is just writing to the db non-stop, as I am sure the nature of the product would keep it busy, but it caused locks and waits and a whole bunch of other sql stuff that I know nothing about. But, if I have learned anything from bigwig tours through the NOC, it is that green is good and red is bad... so NTA has been bad bad bad... emoticons_mischief.png

  • How often are you backing up your Orion database and how much does the transaction log file grow between backups? Multiple product upgrades can result in significant database changes. If those changes haven't yet been committed to the database then I would suggest running a full backup to see where you level off at.

  • I know I have it setup to take full backups nightly.  As for upgrades, we were finally running fairly smooth, with no upgrades having happened, NTA turned off (service on main server, and storage service on NTA storage server), and our log size was around 2gb and steady for about a week or so. After re-enabling the NTA service, that log file just started growing and growing.

  • Ours is also set for nightly backup. I did change it to simple mode.

  • Assuming you're running the latest version of NTA the vast majority of information is stored in a proprietary database outside of SQL. With that said it seems odd to me that NTA would be making such a large volume of adds to the database. If you're not already, I recommend upgrading to NTA v4.1. If that doesn't resolve the issue of your transaction logs growing steadily out of control, please open a case with support so we can determine the root cause of the issue.

  • Setting to simple recovery mode has stopped our drive from filling up.