I was running a trace from session browser and received the attached errors. Would you let me know what the fix is?
could_not_archive.txt (82.9 KB)
could_not_archive.txt (82.9 KB)
I believe the code executing was:
DECLARE
in_filename VARCHAR2(256);
src_file BFILE;
v_content BLOB;
v_blob_len INTEGER;
v_file utl_file.file_type;
v_buffer RAW(32767);
v_amount BINARY_INTEGER := 32767;
v_pos INTEGER := 1;
BEGIN
in_filename := 'edwprod_p038_32680.trc';
src_file := bfilename('TRCA$INPUT2', in_filename);
dbms_lob.fileopen(src_file, dbms_lob.file_readonly);
v_content := utl_compress.lz_compress(src_file, 3);
v_blob_len := dbms_lob.getlength(v_content);
v_file := utl_file.fopen('TRCA$INPUT2',
in_filename || '.gz',
'wb');
WHILE v_pos < v_blob_len LOOP
dbms_lob.READ(v_content, v_amount, v_pos, v_buffer);
utl_file.put_raw(v_file, v_buffer, TRUE);
v_pos := v_pos + v_amount;
END LOOP;
utl_file.fclose(v_file);
:OUT_COMPRESSED_SIZE := Length(v_content);
EXCEPTION
WHEN OTHERS THEN
IF utl_file.is_open(v_file) THEN
utl_file.fclose(v_file);
END IF;
RAISE;
END;
I made some changes in the beta cycle to change the technique of getting a trace file from the server. The old technique was to pull it line by line, and that took a long time for big files.
The new way is to compress the trace file, copy it back to the client, unzip, and open. I assume that the file was zipped and transferred ok and now resides in the location specified in that error message. Can you manually unzip it? If so, you should be able to open it in the trace file browser after you unzip it.
What is your server OS and database version? Maybe there are some Oracle versions that don't zip it as I expect.
-John
I cannot find the file in the folder on my PC. May have been there but not there now. This occurred on a Oracle EE 11.2.0.3 database running on SUSE 11 Linux. I will see if I can reproduce.
Thanks. I'm curious to know if it always fails or sometimes works on this server. Another thing you can check is look on the server and see if the file was zipped. It should be in the same folder as the other trace files.
FYI, that code you're showing is what we do to compress the file.
After that, we run a different pl/sql block to fetch and then delete the compressed file from the server (there is a call to DBMS_LOB.LOADFROMFILE in that block) So if that block never runs, that's a problem, and may be an indication of the first one having problems.
For what it's worth, I just tested this on an 11gR2 database (Windows OS - I don't have SUSE Linux) and didn't have any problems.
I'll add some code to fall back to the old transfer method if the new one fails.
I am able to reproduce but not consistently. I got another new error when trying to reproduce. I am attaching to this thread in case this is somehow related.
ListOfIndexesOutOfBounds.txt (94.0 KB)
That one is different. There is something that Trace File Browser does not like about that trace file to give the LIOOB. If you send me the trace file, I will fix it.
trcfiles.zip.txt (1.9 MB)
I have attached a zip file of the trace files. If am not providing what you asked for please let me know.
Thank you. Yes, that is what I was looking for.
I don't get any error, but there are no SQL statements in this trace file....just a bunch of waits.
I'll try again with 64 bit. Sometimes we get errors in 64 bit but not 32 bit.
Oh! The List Index Out of Bounds error is coming from Session Browser, not Trace File Browser. It has nothing to do with the file requested in my previous reply. Sorry about that.
Can you reproduce that one? If so, can you send me a screen shot of the entire Session Browser immediately before you click "Stop Trace"? And give me some steps to reproduce it? I've seen this error before in call stacks from users but have never been able to reproduce it. If I can reproduce it, I'll fix it.
I will attempt and provide an update shortly.
I have yet to reproduce. I will try again later.
I was able to reproduce the index out of bounds error. Please see the attached.
IndexOutOfBounds.txt (95.6 KB)
Thanks, I'll check that out.
By the way, the "could not open archive file" error is fixed for 15.1. It might not make it into the first beta, but it will be soon after.
Great! Thank you