 Export PROBLEM [message #121810] |
Wed, 01 June 2005 03:11  |
RafalM
Messages: 3
Registered: June 2005
|
Junior Member |
|
|
Hi
Every day I export my db by this command:
exp user/pass buffer=32000 file=exofile log=logfile full=Y inctype=complete
It works fine, backup took about 15 min and occupied 3GB
Someday I want to add parameter direct=Y and it looks like this:
exp user/pass buffer=32000 file=exofile log=logfile full=Y inctype=complete direct=Y
It works fine but:
* It works faster( 
* It occupies half of not direct - 1,5GB
* Every time in alertlog a took this ORA:
ORA-00600: internal error code, arguments: [729], [1819264], [space leak], [], [], [], [], [] Mon May 30 21:17:38 2005 Errors in file .. ora_96264.trc:
ORA-07445: exception encountered: core dump [11] [536842456] [0] [0] [] []
ORA-00600: internal error code, arguments: [729], [1819264], [space leak], [], [], [], [], []
When I switch direct to N it not throw this ORA
What's going on?? Any suggestion
regards
|
|
|
|
| Re: Export PROBLEM [message #121824 is a reply to message #121810] |
Wed, 01 June 2005 04:16  |
girish.rohini
Messages: 744
Registered: April 2005
Location: Delhi (India)
|
Senior Member |
|
|
ORA-600 [729] is a space leak in the UGA.
Also note that space leak is one of those 600 errors which is usually not that serious.
You have basically three possibilities to resolve this:
a) ignore this - it's just a memory leak, no direct threat to your data or/and functionality. You can eventually set your system to ignore small leaks and to not show this error anymore for them. Add the following to your INIT.ORA and bounce your
instance:
event = "10262 trace name context forever, level 2000000"
The level (2000000 in the case above) tells the system not to put ORA-600 error messages in your Alert Log until the space leak is over that number of bytes. In your case, the space leak was 1819264 bytes so a level of 2000000 won't produce this error message.
b) try to apply latest patch
c) contact Oracle support
For further details pls visit http://dbforums.com/t857225.html
|
|
|
|
| Re: Export PROBLEM [message #121833 is a reply to message #121824] |
Wed, 01 June 2005 04:51 |
RafalM
Messages: 3
Registered: June 2005
|
Junior Member |
|
|
Ok so I put this line in paramet file.
I think direct option is much more memory cost method but it so fast and compact.
thanks for advice
best regards
|
|
|
|
| Re: Export PROBLEM [message #121834 is a reply to message #121833] |
Wed, 01 June 2005 05:10 |
girish.rohini
Messages: 744
Registered: April 2005
Location: Delhi (India)
|
Senior Member |
|
|
Well can't say about memory cost, but its definitely faster.
The following para will make it more clear:
Export provides two methods for exporting table data:
Conventional path Export
Direct path Export
Conventional path Export uses the SQL SELECT statement to extract data from tables. Data is read from disk into a buffer cache, and rows are transferred to the evaluating buffer. The data, after passing expression evaluation, is transferred to the Export client, which then writes the data into the export file.
Direct path Export is much faster than conventional path Export because data is read from disk into the buffer cache and rows are transferred directly to the Export client. The evaluating buffer is bypassed. The data is already in the format that Export expects, thus avoiding unnecessary data conversion. The data is transferred to the Export client, which then writes the data into the export file.
|
|
|
|
| Re: Export PROBLEM [message #121836 is a reply to message #121810] |
Wed, 01 June 2005 05:23 |
RafalM
Messages: 3
Registered: June 2005
|
Junior Member |
|
|
Interesting thing is:
1. direct is much more faster
2. it occupies less space (in my case 3G (direct=N) , 1.2GB (direct=Y))
When I set param: recordlength=65535 it did much faster - about 10-20% faster
thanks
|
|
|
|
| Re: Export PROBLEM [message #121842 is a reply to message #121836] |
Wed, 01 June 2005 06:28 |
girish.rohini
Messages: 744
Registered: April 2005
Location: Delhi (India)
|
Senior Member |
|
|
Some facts about export parameters: BUFFER & RECORDLENGTH
BUFFER
Default: operating system-dependent. See your Oracle operating system-specific documentation to determine the default value for this parameter.
Specifies the size, in bytes, of the buffer used to fetch rows. As a result, this parameter determines the maximum number of rows in an array fetched by Export. Use the following formula to calculate the buffer size:
buffer_size = rows_in_array * maximum_row_size
If you specify zero, the Export utility fetches only one row at a time.
Tables with columns of type LONG, LOB, BFILE, REF, ROWID, LOGICAL ROWID, or DATE are fetched one row at a time.
--------------------------------------------------------------------------------
Note:
The BUFFER parameter applies only to conventional path Export. It has no effect on a direct path Export.
RECORDLENGTH
Default: operating system-dependent
Specifies the length, in bytes, of the file record. The RECORDLENGTH parameter is necessary when you must transfer the export file to another operating system that uses a different default value.
If you do not define this parameter, it defaults to your platform-dependent value for buffer size. For more information about the buffer size default value, see your Oracle operating system-specific documentation.
You can set RECORDLENGTH to any value equal to or greater than your system's buffer size. (The highest value is 64 KB.) Changing the RECORDLENGTH parameter affects only the size of data that accumulates before writing to the disk. It does not affect the operating system file block size.
--------------------------------------------------------------------------------
Note:
You can use this parameter to specify the size of the Export I/O buffer.
Source: http://www.stanford.edu/dept/itss/docs/oracle/9i/server.920/a96652/ch01.htm
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
