Unable to login as sys user remotely (although the password file is present and Listner is started).

Today I want to briefly talk about my experience with the login as a sys user. A strange story.

A colleague called me and said that suddenly he can not log in to a pluggable database as a Sys user. It was a 12.1.0.2 Oracle Database. For me something should be because of the fact that the Listner is not started or the password file does not exist or a firewall problem. But the colleague confirmed to me that he can log in remotely with system user and that password file exists. Then I told him to rebuild the password file, maybe the file was just corrupt. Rebuilding the file also did not help. That confused me…..

Rebuilding the file also did not help.
That confused me…..

Then I told him to create a dummy user and grant him sysdba role.
Sys user can only log in as sysdba (or sysoper or sys..) and those users have the particuliarity of having their passwords in the database as well as in the password file on the Oracle Instance. (If one want to log in remotely. The instance does not have to be started, so the password file is needed).

create user dummy identified by dummy;
grant create session to dummy;
grant sysdba to dummy;

amazing he could log in as dummy user but not as sys. As sys he gets the following error message:

ERROR:
ORA-01017: invalid username/password; logon denied

I was confused again. What can the problem be here? Can it be that Sys password is not in the password file?!
That’s not allowed to be true. Then I asked him to look in the view v$pwfile_users:
select * from v$pwfile_users;

And then came the big surprise. In fact Sys User is not in it. How can something like that happen?!
Sys user has sysdba role!

Then … That sounds crazy, I told him to log in as sys user with OS permission and then give sysdba to sys user

sqlplus / as sysdba
grant sysdba to sys;

Then again sys user was found in the view and one could log in remotely as sys with sysdba!

I think it’s strange when you can revoke sysdba role from sys user. Well, I think you can not revoke it. This role has I guess special handling in oracle database.
Otherwise one would not have been able to log in with Os permissions. I believe that „revoke“ only affects the Password File.

I was so busy I did not properly investigate this case. When I had little time again and want to reproduce the problem,
I get the following error message when I try to revoke sysdba from sys:

ORA-01998: REVOKE failed: user SYS always has SYSOPER and SYSDBA

Oracle Datapump Issues

My Experience with Oracle Bug 14202396 in Oracle 11.2.0.4: Datapump remap_data fails if used for more than 10 cols in a table.

I was assigned to write a tool to anonymize an entire database. This should be exported and imported anonymously in another database. The first idea that came to mind was to use „dbms_datapump“. I have good experiences with it and I know that this utility is very flexible and fast. It also offers the possibility to obscure columns on the fly using dbms_datapump.data_remap function.

Before I opted for this solution, I made a proof of concept, then the whole thing was implemented and it was revealed during testing that in some cases, that it does not work at all, and without any reasonable error message! I get the error in some cases at defining the job and before starting it.

ORA-39001: invalid argument value
ORA-06512: in „SYS.DBMS_SYS_ERROR“, line 79
ORA-06512: in „SYS.DBMS_DATAPUMP“, line 3507
ORA-06512: in „SYS.DBMS_DATAPUMP“, line 4309
ORA-06512: in line 66
00000 – „invalid argument value“
*Cause: The user specified API parameters were of the wrong type or
value range. Subsequent messages supplied by
DBMS_DATAPUMP.GET_STATUS will further describe the error.
*Action: Correct the bad argument and retry the API.

There was no error or hint in the Oracle Alert file. To narrow down the problem, I have written the following test block:

DECLARE
  STMT VARCHAR2(32767);
  tbl_name VARCHAR2(30) := UPPER('TEST_TABLE$$$$');
  fu_name varchar2(100) := 'PKG_OBFUS_DATA.FU_1';
  v_job_state user_datapump_jobs.state%TYPE;
  v_exp_job_name varchar2(30) := 'exp_dmp_i_m_just_tst';
  h1 NUMBER;
  g_dbdir VARCHAR2(30) := 'DATA_PUMP_DIR';
  NUMBER_OF_COL_TO_TEST BINARY_INTEGER := 11; --  <= 10 works , > 10 error at job definition (11.2.0.4). But in 12.2 it works fine
  v_col_name VARCHAR2(30) := 'COL_1';
BEGIN
  BEGIN
    EXECUTE IMMEDIATE 'drop table '||tbl_name||' purge';
  EXCEPTION
    WHEN OTHERS THEN
      dbms_output.put_line('table does''t exist....');
  END;
  --generate table code with 20 colums
  FOR REC IN (SELECT A
                FROM (SELECT 'create table '||tbl_name||'   (' A
                        FROM DUAL
                      UNION ALL
                      SELECT DECODE(ROWNUM, 1, NULL, ',') || 'col_' || ROWNUM ||
                             ' varchar2(100)'
                        FROM DUAL
                      CONNECT BY LEVEL < 21
                      UNION ALL
                      SELECT ') nologging compress'
                        FROM DUAL)) LOOP
    STMT := STMT || REC.A || CHR(10);
  END LOOP;
  DBMS_OUTPUT.PUT_LINE(STMT);
  -- create the table
  EXECUTE IMMEDIATE STMT;
  --generate insert stmt
  select 'insert into '||tbl_name||' values ('||listagg(''''||column_name||'''' , ',') within group(order by column_id) || ')' 
  INTO stmt 
  FROM user_tab_cols where table_name = tbl_name ;
  --insert just one row ;
  EXECUTE IMMEDIATE stmt;
  dbms_output.put_line(SQL%ROWCOUNT || ' row inserted in '||tbl_name||'' ) ;
  COMMIT;
  -- create obfus function (it works only for functions in pkg)
  --head
  EXECUTE IMMEDIATE 'CREATE OR REPLACE PACKAGE PKG_OBFUS_DATA IS FUNCTION FU_1(p_in VARCHAR2) RETURN VARCHAR2; END;';
  --body
  EXECUTE IMMEDIATE 'CREATE OR REPLACE PACKAGE BODY PKG_OBFUS_DATA IS FUNCTION FU_1(p_in VARCHAR2) RETURN VARCHAR2 IS
                      BEGIN RETURN ''test''; END;  END;';
  
  -- test datapump
  h1 := dbms_datapump.open(operation => 'EXPORT',job_mode => 'TABLE',job_name => v_exp_job_name);
  dbms_datapump.add_file(handle => h1, filename => 'delete_me_if_u_see_me.dmp' ,directory => g_dbdir, reusefile  => 1);
  dbms_datapump.metadata_filter(h1,'NAME_EXPR', ' IN ('''||tbl_name||''')');
  DBMS_DATAPUMP.metadata_filter(h1,'SCHEMA_EXPR',  'IN ('''||USER||''')');
  dbms_output.put_line('ok');
  --dbms_datapump.data_remap(handle => h1, name => 'COLUMN_FUNCTION', 
  --  table_name => tbl_name, column => v_col_name, function => fu_name, schema => 'SMARAGD_DBA');
  FOR i IN 1..NUMBER_OF_COL_TO_TEST LOOP
    dbms_output.put_line(i);
    dbms_datapump.data_remap(handle => h1, name => 'COLUMN_FUNCTION', 
    table_name => tbl_name, column => 'COL_'||i, function => fu_name, schema => 'SMARAGD_DBA');

  END LOOP;
  --definition is ok
  dbms_datapump.start_job(h1);
  dbms_datapump.wait_for_job(h1, v_job_state);
  --cleanup
  EXECUTE IMMEDIATE 'drop table '||tbl_name||' purge';
  EXECUTE IMMEDIATE 'drop package PKG_OBFUS_DATA';
END;

The test block simply creates a table with 20 columns, a test function for anonymization. And I made runs. I was surprised: the program works as long as the number of anonymised columns is less than 10! I could not believe it, Oracle developers forgot something here or is that just a restriction?!
In the doc I found no  things about this limitation and the error message does not say much. Then I posted the question in a forum, one responded quickly and told me that he had the same problem. He said: We opened a SR for it at the time, and Oracle’s response was that you need to purchase Oracle Data Redaction if the built-in Datapump limit is insufficient. I was pretty disappointed. I did not want to lose much time on this topic then
I have a workaround built in, which cost me two days.

Later I found out that Oracle does not have any restrictions here, but it was just a bug. After installing the OPatch everything worked fine as expected.

Oracle reading alert log via sql

In many situations, an Oracle developer needs access to the alert log file to explain some problems occurring on the database. Errors that may be logged there are e.g. problems with tablespaces, online / archive log files, deadlocks or Ora-00600 errors. In the event of serious errors, detailed information is logged in trace files. The trace file name is written in the alert file. However, the alert file is located on the Oracle server and the developers usually do not have access to the Oracle server. Well, we are going to see how we can still access the content of this file through SQL.

From my own experience during the installation a new version of our software at the customer. The customer in Germany has a RAC database with two nodes. The database instances were somewhere in France. It was Friday very late and our software aborts when executing an SQL statement. The sessions just disappear without leaving any traces in our software logging. The DBA in France was unfortunately not available at this time (It was quite simply very late on Friday). In the log of our software, I could find nothing relevant. It was clear that the problem has to do with the Oracle Instance. In such cases, it would be very helpful to take look in the alert file for more information.

Then I came up with the following idea (I already knew that something like that is possible, I’ve read in a book): Luckily we had a database user who is allowed to create directories, external table and has select privelige on gv$process and gv$instance.

Why GV$INSTANCE? Because it was a RAC database so several nodes therefore GV$
The Alert file is called (most) alert_SID.log, where SID is instance_name: SELECT instance_name  FROM GV$INSTANCE

Why GV$PROCESS? Because tt was a RAC database so several nodes therefore GV$ With following query you can get the full path on the OS of the alert file.

SELECT DISTINCT INST_ID,SUBSTR(TRACEFILE,1,INSTR(TRACEFILE, '/', -1)) A  FROM GV$PROCESS 

This block conveniently generates the code to create the directories and the tables:

DECLARE
  STMT VARCHAR2(4000) := 'create table 
   alert_log__inst?int? ( msg varchar2(1024) )
organization external (
   type oracle_loader
   default directory dir4alertfile?int?
   access parameters (
      records delimited by newline
   )
   location(''alert_?SID?.log'')
)
reject limit 100000';
BEGIN
  FOR REC IN (SELECT INSTANCE_NAME, P.*
                FROM GV$INSTANCE I
                JOIN (SELECT DISTINCT INST_ID,
                                     SUBSTR(TRACEFILE,
                                            1,
                                            INSTR(TRACEFILE, '/', -1)) A
                       FROM GV$PROCESS) P
                  ON I.INST_ID = P.INST_ID) LOOP
    DBMS_OUTPUT.PUT_LINE('CREATE OR REPLACE directory dir4alertfile' ||
                         REC.INST_ID || ' as ''' || REC.A || '''');
    DBMS_OUTPUT.PUT_LINE(CHR(10) || CHR(10));
    DBMS_OUTPUT.PUT_LINE(REPLACE(REPLACE(STMT, '?int?', REC.INST_ID),
                                 '?SID?',
                                 REC.INSTANCE_NAME));
    DBMS_OUTPUT.PUT_LINE(CHR(10) || CHR(10));
  END LOOP;
END;

generated code:

--first directory (node1)
CREATE OR REPLACE directory dir4alertfile1 as '/u01/app/oracle/diag/rdbms/mydb/INST1/trace/'


--first external table (node1)
create table
   alert_log__inst1 ( msg varchar2(1024) )
organization external (
   type oracle_loader
   default directory dir4alertfile1
   access parameters (
      records delimited by newline
   )
   location('alert_INST1.log')
)
reject limit 100000

--second directory (node2)
CREATE OR REPLACE directory dir4alertfile2 as '/u01/app/oracle/diag/rdbms/mydb/INST2/trace/'


--second external table (node2)
create table
   alert_log__inst2 ( msg varchar2(1024) )
organization external (
   type oracle_loader
   default directory dir4alertfile2
   access parameters (
      records delimited by newline
   )
   location('alert_INST2.log')
)
reject limit 100000

We can use the same to read in the trace files.