We had recently upgraded our NBU OpsCenter server from v188.8.131.52 to v184.108.40.206, As per Symantec recommendation/steps we had performed the upgradation activity and it was successful one.
Post the upgradation, I could see there is a temp file “sqla0001.tmp” created in the C:\ drive which occupies 10 GB of space, this resulted in creating a P2 incident daily which the drive space is occupied by the temp file. Also its taking a long time to generate the reports manually.
As per the tech note http://www.symantec.com/business/support/index?page=content&id=TECH152870 I have changed the location of this file from C:\ drive to D:\ drive (OpsCenter software is installed in this drive)and this file was having more than 70 GB of free space, However after changing the path this file grows massively and created a temp file as “sqla0001.tmp” in D:\ drive which occupies 57+ GB of space. This resulted P2 incident for space crunch in D: drive.
Also i do not have any idea why this file has grown rapidly from 10+ GB to 50+GB.
Could someone help me out to fix this issue, it would be appreciated if this temp file is disabled/not created in any of the directory.
Kindly help me on this , Thanks !
I can't find this file in my OpsCenter server, not in 220.127.116.11, nor in 18.104.22.168 when i patch it.
It looks like temp file created by the Sybase (dbsrv), all i can find from Netbackup is that technote you mentioned. Not sure if it can be disabled, maybe a call to Netbackup support is worth to resolve this - I would expect server.conf has some kind of switch to turn it off..
Otherwise, would have to use Windows task manager to schedule the cleanup every few hours.
Hi, our OpsCenter is having the same issue as describe here. We opened a Case # 06756537 on June 13. So far support and I weren't able to get this control. We did some config file tune up to limited the issue, but the only work around so far is to run a "task scheduler" to defrag DB.
Our TMP file is 12GB, isn't as big as your, but Symantec thought we are the only customer facing this issue they can't replicate in their lab. Current answer is "From what backline told [...] there is no set normal size of operation"
I'm glad we have another customer facing same issue. I'll report this to my case ID.
Hello Mr.Fox Foot,just wondering if defrag helped you to resolve this issue ?
Couimette, you mentioned " the only work around so far is to run a "task scheduler" to defrag DB.". Do you mean a defrag reduces the file size but it grew back again ? What is the version of Opscenter and did it occur after upgrade ?
Actually, you don't need to defrag DB to clear it. When you run a defrag, I think db is started/stoped, so why it would also clear. We saw TMP going away after stop completed. Maybe the defrag will help not having it back very high, but I don't remember. A OpsCenter TMP file at 12GB for days stopped and started again is now 15MB after 15min. It will come back to couple GB, I think it takes couple days.
But Symantec told us there is typical size and that no other customer facing this issue - but I ever heard that one :)
We have 7.6 maintenance pack 2.
Apologies for delay in replying to this post.
Deeps – I Agree with Couimette comments, DB Defrag will not help us in this scenario. I had performed DB Defrag twice and DB Validation once in last to verify this issue occurred due to corrupted DB.
Also increased the page file settings as recommended by Symantec TSE.
Our OpsCenter server DB size is 25 GB in Size in normal. When we run DB defrag it reduce in size of 2 – 3 GB, Approx. it will reach 22 GB in size post the DB defragmentation.
the TMP file “sqla0001.tmp” is grown up to 69.5 GB. As a workaround when I will to restart the opsadmin service, especially when the DB service is restarted it will release the hold on this temp file and this file will be vanished which resulted in more free space. Post the DB services are up, this tmp file will be created and as said by “Couimette”, it will grow and it will reach more than 40+ GB in couple of days.
I do had opened a case with Symantec, still I have not heard of any permanent solution.
Expecting a permanent solution to fix this issue. Thanks !
found this, have not tried it myself
It's easy to tell SQL Anywhere where to put the temporary file: just use the dbsrv12 -dt option or one of the SATMP, TMP, TMPDIR or TEMP environment variables.
The next step, telling SQL Anywhere to stop runaway connections from using too much temporary space, is harder. Here's how...
Step 1: Put a limit on temporary space usage
Pick a limit, say 512M, on the amount of temporary storage used by each individual connection, and put that limit into effect:
SET OPTION PUBLIC.temp_space_limit_check = 'On';
SET OPTION PUBLIC.max_temp_space = '512M';