Thursday, 12 September 2013

tar: Error exit delayed from previous errors

Another Linux related post: I was trying to tar up the oracle software and I was getting a strange message at the end of the tar output:


>tar -cvf 11.2.0.tar 11.2.0

11.2.0/
11.2.0/timingframework/
11.2.0/timingframework/TimingFramework.jar
11.2.0/timingframework/README
11.2.0/OPatch/
11.2.0/OPatch/opatchprereqs/
11.2.0/OPatch/opatchprereqs/prerequisite.properties
11.2.0/OPatch/opatchprereqs/opatch/
11.2.0/OPatch/opatchprereqs/opatch/runtime_prereq.xml
-----
-----

tar: Error exit delayed from previous errors

The challenge here is to find out the root cause of this general error message.

Solution:

Run the tar command again, while redirecting the error output to a log file:

tar -cvf 11.2.0.tar 11.2.0  2> tar.log

In my case, the content of the log file solved the "mystery":

tar: 11.2.0/bin/nmhs: Cannot open: Permission denied
tar: 11.2.0/bin/nmb: Cannot open: Permission denied
tar: 11.2.0/bin/nmo: Cannot open: Permission denied
tar: Error exit delayed from previous errors





Sunday, 8 September 2013

Loading an Excel file using sqlldr and "corrupted" French characters

The issue: using as input file an Excel file, 1.csv , we load it using sqlldr utility to the database and when querying the newly inserted data, the French characters seem corrupted.

The control file used is as follows:

LOAD DATA
CHARACTERSET UTF8  ---------> solution provided by the developer :-)
infile '1.csv'
APPEND
INTO TABLE  my_table
fields terminated by "," optionally enclosed by '"'
TRAILING NULLCOLS
(empno,alert_end_Date date "mm/dd/yyyy",alert_text char(500000),alert_title,emp_no)


Solution: use CHARACTERSET WE8ISO8859P1 inside the control file, or just remove the characterset entry.

LOAD DATA
CHARACTERSET WE8ISO8859P1  ---------> this has to be the same as nls_lang of the DB , see note below
infile '1.csv'
APPEND
INTO TABLE  my_table
fields terminated by "," optionally enclosed by '"'
TRAILING NULLCOLS
(empno,alert_end_Date date "mm/dd/yyyy",alert_text char(500000),alert_title,emp_no)


 Note : to find out the NLS LANG of the DB:


 select DECODE(parameter, 'NLS_CHARACTERSET', 'CHARACTER SET',
'NLS_LANGUAGE', 'LANGUAGE',
'NLS_TERRITORY', 'TERRITORY') name,
value from v$nls_parameters
WHERE parameter IN ( 'NLS_CHARACTERSET', 'NLS_LANGUAGE', 'NLS_TERRITORY')
/

NAME VALUE
————- —————–
LANGUAGE AMERICAN
TERRITORY AMERICA
CHARACTER SET WE8ISO8859P1


Thursday, 8 August 2013

Foreign keys and "on delete cascade" for a few delete statements only

Let assume that we have 2 tables, in a parent-child relationship, but the foreign key was created without "on delete cascade"; we want to run a few delete statements on the parent table, which should be cascaded to the child table and after the completion we want to restore the initial mode.

One way to do it is to delete from the child table first and then from the parent table, but this may pose a challenge, we only have conditions for delete for the parent table.

The solution will be re-create the existing foreign key with "on delete cascade", run all the delete statements and after that re-create the FK again, this time exactly as it was before.

Below is a small example:


SQL> create table parent (
  2  col1_parent number not null);

Table created.


SQL> alter table parent add constraint parent_pk primary key (col1_parent);

Table altered.


SQL> insert into parent values(1);

1 row created.

SQL> insert into parent values(2);

1 row created.

SQL> insert into parent values(3);

1 row created.


SQL> create table child (
  2   col1_child number,
  3  FOREIGN KEY (col1_child) REFERENCES parent(col1_parent) );

Table created.


 * To delete 1 row from the parent table, we first must delete from the child:


SQL> delete from parent where COL1_PARENT=1;
delete from parent where COL1_PARENT=1
*
ERROR at line 1:
ORA-02292: integrity constraint (FLORINM.SYS_C001881207) violated - child
record found


SQL> delete from child where col1_child=1;

1 row deleted.

SQL> delete from parent where COL1_PARENT=1;

1 row deleted.


 * Assume we'd like to delete a few rows from parent, that we'll be cascaded to the child, as a one time thing only:


SQL> insert into child values(2);

1 row created.

SQL> insert into child values(3);

1 row created.

SQL> insert into parent values(10);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from parent;

COL1_PARENT
-----------
          2
          3
         10

SQL> select * from child;

COL1_CHILD
----------
         2
         3



  1* select table_name,constraint_name,constraint_type from user_constraints
SQL> i
  2  where table_name in ('PARENT','CHILD');

TABLE_NAME                     CONSTRAINT_NAME                C
------------------------------ ------------------------------ -
CHILD                          SYS_C001881207                 R
PARENT                         SYS_C001881205                 C
PARENT                         PARENT_PK                      P




SQL> alter table CHILD add constraint CHILD_FK foreign key (col1_child) references parent(col1_parent) on delete cascade;

Table altered.


SQL> select * from parent;

COL1_PARENT
-----------
          2
          3
         10

SQL> select * from child;

COL1_CHILD
----------
         2
         3

SQL> delete parent;

3 rows deleted.

SQL> select * from child;

no rows selected


SQL> alter table CHILD drop constraint CHILD_FK;

Table altered.

SQL> alter table CHILD add constraint CHILD_FK foreign key (col1_child) references parent(col1_parent);

Table altered.



Friday, 2 August 2013

How to check and modify the AWR settings?

I've decided to write this post, since every time I need to check/modify the AWR snapshot settings, I never remember the exact views and procedures to use.
So here they are:

1) Getting the current AWR snapshot settings:

SQL> select * from dba_hist_wr_control;

      DBID SNAP_INTERVAL                                                               RETENTION                                                                   TOPNSQL
---------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
2560013153 +00000 00:10:00.0                                                           +00010 00:00:00.0                                                           DEFAULT


What this means is that the snapshots are running every 10 minutes and the retention time is 10 days.


2) Modifying the snapshot interval to every 15 minutes and retention time to 31 days only:

SQL> execute dbms_workload_repository.modify_snapshot_settings( interval => 15,retention => 44640);


 interval is in minutes, retention also.


SQL> select * from dba_hist_wr_control;

      DBID SNAP_INTERVAL                                                               RETENTION                                                                   TOPNSQL
---------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
2560013153 +00000 00:15:00.0                                                           +000031 00:00:00.0                                                           DEFAULT

Tuesday, 9 July 2013

Oracle 11g: datapump with option COMPRESSION=ALL

Test case: we have a relatively big table, around 60 GB of uncompressed data; the table is compressed and takes only 4 GB. We need to copy this data to a different database, as fast as possible and also without taking too much disk space.

Solution:  datapump to the rescue :-)
While regular exp/imp utilities do not handle well compressed tables, expdp will export the table, while keeping it compressed. Sample of parfile used for the export:

userid=mydbuser/passwd
dumpfile=mytab_extract.dmp
logfile=mytab_extract.exp.log
parallel=16
tables=mytab
directory=big_dmp
compression=ALL


Conclusion: expdp is handling very well compressed tables, generating a dump file similar in size with the size of the compressed table itself.

Wednesday, 26 June 2013

How to remove duplicate rows from a table

Sometimes, the application is inserting "duplicate" rows in a table, let's assume the uniqueness is supposed to be ensured using col1, col2 and col3.
In the case the number of duplicate rows is reasonably small and that we don't really care which row we leave/delete out f the duplicate ones, we could use the delete below to eliminate these rows.
In the case where the number of duplicate is very big, we need to avoid the delete and use "create table as select", to leave only the desired rows.


DELETE FROM dup_table
WHERE rowid not in
(SELECT MIN(rowid)
FROM dup_table
GROUP BY column1, column2, column3);

Monday, 17 June 2013

How to trace remote oracle connections, on the client side?

In order to trace oracle remote connections on the client side, first we need to add a few entries to the sqlnet.ora file; for example, to set trace at the highest level, for oracle support, we need level 16:

 box1:/u01/app/oracle/client_trace> cat /etc/sqlnet.ora
TRACE_LEVEL_CLIENT=16
TRACE_DIRECTORY_CLIENT=/u01/app/oracle/client_trace
LOG_DIRECTORY_CLIENT=/u01/app/oracle/client_trace
TRACE_TIMESTAMP_CLIENT=ON
DIAG_ADR_ENABLED=OFF

The last line, disabling diag is required starting with 11G.

In addition, there are two more steps to follow, to make sure that the trace/log file will be generated as expected:

1) Oracle will look for sqlnet.ora in $ORACLE_HOME/networking/admin, by default, so either update the file in this location or define TNS_ADMIN, in the environment where the connection to the DB is taking place.
2) Make sure the directory destination for trace/log files it has read/write permission for the owner of the process you want to trace; oracle will silently ignore your request and just it won't generate the trace file otherwise.