Fast Guide: PL/SQL

Fast Guide: PL/SQL: "Fast Guide: PL/SQL"

IMP-00017: following statement failed with ORACLE error 2304

Oracle import fails when importing into the same database but to a different schema, with this error. Problem is the type is exported with its object id (OID) in it's definition. When oracle tries to recreate it in a different schema it fails because OID is unique database wide. Here are the solutions.

On oracle 8i when using fromuser/touser, see the following
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1323002416801

On oracle 10.1 when using REMAP_SCHEMA
Create the types and tables dependent on those type and then use the option TABLE_EXISTS_ACTION=append on impdp

On oracle 10.2 when using REMAP_SCHEMA
use option TRANSFORM=oid:n on impdp

here are the metalink notes:
Note: 351519.1 - Import of Object Types Fails With ORA-39083 ORA-02304 or ORA-39117 ORA-39779
Note: 1066139.6 "IMP-17 IMP-3 ORA-2304 IMP-63 FROMUSER/TOUSER Import of Table With Object Column"
Note :1066139.6 - IMP-17 IMP-3 ORA-2304 IMP-63 FROMUSER/TOUSER Import of Table With Object Column

ORA-19511: VERITAS NetBackup: Status 25: Cannot connect on socket

Status 25: "Cannot connect on socket"

Exact Error Message
25 cannot connect on socket

Details:
Overview:
When performing backups or restores, socket errors are being produced.

Troubleshooting:
Please follow all steps within the VERITAS NetBackup (tm) Troubleshooting Guide or the NetBackup Troubleshooter within the Activity Monitor for this status code before continuing.

Please confirm hardware and software compatibility before continuing. A list of compatible hardware and software may be obtained within the VERITAS NetBackup Release Notes or on the VERITAS Support Web site.

If the above does not resolve the issue, please continue.


1. Status code 25 caused by no open sockets on the Master/Media Server

Please look for the following log messages:

Master Log Files:

Media Server Log Files:
bpbrm:
02:44:21.877 [1092.2944] <2> nb_bind_on_port_addr: port 4998 unavailable
02:44:21.877 [1092.2944] <2> nb_getsockconnected: cannot connect() to MasterServer, Only one usage of each socket address (protocol/network address/port) is normally permitted.
02:44:21.877 [1092.2944] <2> db_begin: nb_getsockconnected() failed: Only one usage of each socket address (protocol/network address/port) is normally permitted. (10048)
02:44:21.877 [1092.2944] <2> db_FLISTsend: db_begin() failed: cannot connect on socket
02:44:21.877 [1092.2944] <16> bpbrm handle_backup: db_FLISTsend failed: cannot connect on socket (25)
02:44:21.877 [1092.2944] <2> nb_bind_on_port_addr: port 4999 unavailable

Client Log Files:

Resolution:
A socket in a TIME_WAIT state may be made available sooner by reducing the tcp_time_wait_interval parameter. The default for this parameter on Solaris is 240000 milliseconds or 4 minutes. The default for Hewlett-Packard (HP) is a value of 60000 milliseconds or 1 minute. The default on AIX is set in increments of 15 seconds. The default value is 1 or 15 seconds. On AIX, this is the lowest it may be set to. VERITAS has found that the tcp_time_wait_interval can often be set to 1 second with no adverse effects. However, customers should adjust the TCP_TIME_WAIT_INTERVAL in increments; lowering the value until backups no longer fail with the status 25.

The value of this parameter may be obtained and changed by running the following command:

For Solaris 2.6 or earlier:

#ndd -get /dev/tcp tcp_close_wait_interval
#240000
#ndd -set /dev/tcp tcp_close_wait_interval 10000 (10 seconds)


For Solaris 7 or later:

#ndd -get /dev/tcp tcp_time_wait_interval
#240000
#ndd -set /dev/tcp tcp_time_wait_interval 10000 (10 seconds)


The ndd command makes the change immediately, without a need for a reboot. This setting will go back to default after a reboot. To make the change permanent, the command can be added to the appropriate TCP/IP startup script. On Solaris, this is /etc/rc2.d/S69inet.

For HP-UX 11, use the following command:

#ndd -get /dev/tcp tcp_time_wait_interval
#60000
#ndd -set /dev/tcp tcp_time_wait_interval 10000 (10 seconds)

Note: The equivalent command on HP-UX 10.x is nettune instead of ndd.

The ndd command makes the change immediately, without a need for a reboot. This setting will go back to default after a reboot. To make the change permanent, the command can be added to the appropriate TCP/IP startup script. On HP-UX 11, see /etc/rc.config.d/nddconf for examples on how to set it.

It is not necessary to change the tcp_timewait default parameter on AIX, but for reference:

To display the value, enter:
#no -a
or
#no -o tcp_timewait

To change the value, enter:
#no -o tcp_timewait=1

Where is a positive integer, with each increment representing 15 seconds. The default is 1 for 15 seconds. The change takes effect immediately. The change is effective until the next boot. A permanent change is made by adding the command to /etc/rc.net.

Windows System:
Ports in TIME_WAIT will be seen by running netstat -a from a command prompt on the master or media server. This can be an indication that ports are not being released quickly enough to allow another connection on that port. The registry setting TcpTimedWaitDelay can be added to reduce the time a port will stay in this state.

1. Go to Start | Run, type regedit, and click OK
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Highlight the Parameters key, right-click and select New | DWORD Value
4. Type the name TcpTimedWaitDelay
5. Double-click TcpTimedWaitDelay and enter a decimal value of 30
By default, this value is 240 seconds (4 minutes). It is recommended that this be changed to a value between 30-60 (seconds) in decimal, to decrease the wait time before a port becomes available.

Description:
This parameter determines the length of time that a connection will stay in the TIME_WAIT state when being closed. While a connection is in the TIME_WAIT state, the socket pair cannot be re-used. This is also known as the "2MSL" state, as by RFC the value should be twice the maximum segment lifetime on the network. See RFC793 for further details.