on 01-25-2013 8:10 AM
Hi Akihiro,
on linux level you can easily navigate to the trace files of one host via the pre-defined shell alias cdtrace:
alias cdtrace='cd $DIR_INSTANCE/$VTHOSTNAME/trace'
As you can see in the path above, the trace files are stored separated per host.
So to get access to the trace files of a multi-node system you'd have to check different paths for each host.
From within SAP HANA you can query the location of the trace files via the monitoring view m_disks:
select * from m_disks where usage_type ='TRACE'
Generally a much more convenient approach to access the files and the contents of the files are the views m_tracefiles and m_tracefile_contents.
While the actual trace information is stored in the files, you can still just select these views to read the data in them.
On top of that, if you don't want to iterate over all files yourself, give m_merged_traces a try.
This view automatically reads all the standard trace files of all nodes and generates a combined overview.
As you can imagine this takes a while - and it is executed every time you select from this view.
Thus, if working with the data from this view it might be a good idea to load its content to a temporary table first and operate on this further.
This is, by the way, the way SAP HANA studio presents the merged diagnosis files.
- Lars
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Akihiro,
the easiest way to get rid of the trace files is to select them in the trace files list in SAP HANA Studio and choose "DELETE" from the context menu.
Unfortunately, for those trace files that are still opened by the indexserver process, the files will disappear from the list (and from the directory) but the storage space will only be released after a restart of the indexserver process.
- Lars
Yes, the trace files will be recreated again, if needed.
I wouldn't recommend to delete any of the .001, .002 ... numbered trace files as there should be just 10 of them for each service at a time (although the numbers continuously are counted up).
And these should only take about 10MB each.
What's probably taking more space are large crash dumps, maybe even from revisions you don't use any more.
These can be safely deleted.
- Lars
This message was moderated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
86 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.