huge RT_LOG
Moderators: chulett, rschirm, roy
huge RT_LOG
I am having a huge RTLOG file, although I have kept autopurge for every 10 days option.
Why will happen as such and any way to remove it, as its causing space issue.
Why will happen as such and any way to remove it, as its causing space issue.
RT_LOG will be suffixed by a three digit number. Use that number to find what job it is (use the below query in the Administrator) and then go clear that jobs log from the director.
where nnn= your job number
Code: Select all
SELECT NAME FROM DS_JOBS WHERE JOBNO = 'nnn';
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
But first you need to figure out why it is getting to be 'huge'. Is your job aborting? Keep in mind the fact that aborted jobs don't 'auto-clear' their logs.
Otherwise, the other thing that comes to mind are it must be chocked full of warnings. There's no reason a Server job should ever log a warning, it's a sign of either a flaw in the job's design or a database/tablespace/filespace issue that needs to be resolved. We see this when someone runs a job allowing unlimited warnings because they don't want it to abort - is that what you are doing?
If not, please let us know what in the heck you are finding in these huge logs.
Otherwise, the other thing that comes to mind are it must be chocked full of warnings. There's no reason a Server job should ever log a warning, it's a sign of either a flaw in the job's design or a database/tablespace/filespace issue that needs to be resolved. We see this when someone runs a job allowing unlimited warnings because they don't want it to abort - is that what you are doing?
If not, please let us know what in the heck you are finding in these huge logs.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Are you sure it was deleted? Space issues in the DataStage installation filesystem can corrupt everything and make stuff 'disappear'. Search the forum for DS.TOOLS or DS.REINDEX for discussions on rebuilding the repository indices.
Otherwise - Repromote it from Version Control. Reimport using the Manager, either from Dev or a backup. Worst case, you'll need to recreate it.
Otherwise - Repromote it from Version Control. Reimport using the Manager, either from Dev or a backup. Worst case, you'll need to recreate it.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
This job was not part of the design, so I wouldnt be bothered if its gone, We have backup of the job which are part of the design. But the log file from this is creating space problems. (just found from another version, that it gives plenty of warnings)
The RT_LOGnnn is still in there.
when I open the director, it gives an error
Or can I usesomething like that? I tried using but didnt work
I also tried to replace it with new job, with same name. Will it be safe now to use mv command or will it create problems
The RT_LOGnnn is still in there.
when I open the director, it gives an error
Code: Select all
DataStage Reporsitory Interface
Failed to open RT_LOGnnn
Or can I use
Code: Select all
DELETE FROM VOC WHERE NAME=''
Code: Select all
CLEAR.FILE
I also tried to replace it with new job, with same name. Will it be safe now to use mv command or will it create problems
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Use DS.CHECKER
However, if you have already inflicted damage (like deleting a VOC entry), then DS.CHECKER will not work, and you will need to clear things manually.
Let us know.
Then analyze why the warnings are being generated, and re-design the job with a view to preventing them from occurring. No server job should ever generate a warning unless it is caused by environmental or data factors.
However, if you have already inflicted damage (like deleting a VOC entry), then DS.CHECKER will not work, and you will need to clear things manually.
Let us know.
Then analyze why the warnings are being generated, and re-design the job with a view to preventing them from occurring. No server job should ever generate a warning unless it is caused by environmental or data factors.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.