I'm learning the OLS (Oracle Label Security) feature of Oracle, and here is my problem.
I executed those procedures to enabled the OLS feature. My current user was sys who have the sysdba privilege.
EXEC LBACSYS.CONFIGURE_OLS;
EXEC LBACSYS.OLS_ENFORCEMENT.ENABLE_OLS;
Then I logged in by LBACSYS account to create the OLS Policy, but it not worked.
CONN LBACSYS/LBACSYS;
BEGIN
SA_SYSDBA.CREATE_POLICY (
policy_name => 'emp_ols_pol',
column_name => 'ols_col',
default_options => 'read_control, update_control');
END;
/
Error messages
Error report -
ORA-65109: operation not allowed in CDB$ROOT
ORA-06512: at "LBACSYS.LBAC_LGSTNDBY_UTIL", line 100
ORA-06512: at "LBACSYS.LBAC_SYSDBA", line 80
ORA-06512: at "LBACSYS.LBAC_SYSDBA", line 138
ORA-06512: at "LBACSYS.LBAC_LGSTNDBY_UTIL", line 76
ORA-06512: at "LBACSYS.SA_SYSDBA", line 16
ORA-06512: at line 2
65109. 00000 - "operation not allowed in CDB$ROOT"
*Cause: An operation was attempted that is not supported in the Container
Database root.
*Action: Switch to a pluggable database to perform the operation.
Help me please, and thank you guys a lot!
Related
Guys i have a problem with this error at ORACLE i think is permissions but i don't know where can i do something.
HELP!
ORA-20123: ERROR DMM_INTER_STOCK_SAP: ORA-29283: invalid file operation
ORA-06512: at "SYS.UTL_FILE", line 536
ORA-29283: invalid file operation
ORA-06512: in "DMM.GEN_PKG_INTER" line 973
ORA-06512: online 2
The process has finished.
DIRECTORY_NAME DIR_DEP_DMM_BK
DIRECTORY_PATH /oracle/app/oracle/file/DEP/DMM/BK
Privilege list EXECUTE, READ, WRITE
ORA-06512: at "SYS.UTL_FILE", line 536
means you got the error during an FOPEN call. You need to ensure that the OS and the database are "in alignment" in terms of permissions.
The database privs you have listed indicate you can read/write the directory object. But you also need to check the OS directory /oracle/app/oracle/file/DEP/DMM/BK that it (a) exists, and (b) can be written to by the database OS account (typically 'oracle').
Most of the answers I've seen are for Linux. Windows permissions have an element of black magic about them. This is Windows Server 2016.
I created the d:\data\transfer\sirius\ directory on the Oracle database server.
As SYSDBA I do the following:
create or replace directory SIRIUS_DIR as 'd:\data\transfer\sirius\';
grant read,write on directory SIRIUS_DIR to SIRIUS;
Then on another server, in a SQL*Plus session as the SIRIUS user, I run:
DECLARE myFile utl_file.file_type;
BEGIN
myFile := utl_file.fopen('SIRIUS_DIR ', 'random.txt', 'w', 32000);
END;
/
Which gives:
ERROR at line 1:
ORA-29283: invalid file operation
ORA-06512: at "SYS.UTL_FILE", line 536
ORA-29283: invalid file operation
ORA-06512: at "SYS.UTL_FILE", line 41
ORA-06512: at "SYS.UTL_FILE", line 478
ORA-06512: at line 3
How to proceed?
Figured it out. You need to grant full access to the ORA_INSTALL group to the directory in question on the database. According to the Oracle configuration docs:
The ORA_INSTALL group contains all the Oracle Home Users for all
Oracle homes on the server.
Thanks to this kindly blogger for his solution.
I'm trying to configure Oracle XStream out by official documentation
So, shortly, I'm connecting as sysdba
sqlplus / as sysdba
Then executing commands create create CDB user and give him privileges
> CREATE TABLESPACE xstream_tbs DATAFILE '$ORACLE/cdb/orcl/xstream_tbs.dbf' SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
> CREATE USER c##xstrmadmin IDENTIFIED BY password DEFAULT TABLESPACE xstream_tbs QUOTA UNLIMITED ON xstream_tbs container=all;
> GRANT CREATE SESSION, SET CONTAINER TO c##xstrmadmin CONTAINER=ALL;
After this step I should give permissions to user to use XStream
> BEGIN
DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGE(
grantee => 'c##xstrmadmin',
privilege_type => 'CAPTURE',
grant_select_privileges => TRUE,
container => 'ALL');
END;
/
On this stage, I'm getting this error:
ERROR at line 1:
ORA-44001: invalid schema
ORA-06512: at "SYS.DBMS_XSTREAM_AUTH_IVK", line 3383
ORA-06512: at line 1
ORA-06512: at "SYS.DBMS_XSTREAM_AUTH_IVK", line 3500
ORA-06512: at "SYS.DBMS_XSTREAM_AUTH", line 34
ORA-06512: at line 2
Current container is cdb$root
Googling gives actually nothing and I have no idea whats wrong as I'm following DBA documentation.
I guess I found workaround.
If you connect to oracle with
> sqlplus /nolog
And then connect as sysdba
> conn / as sysdba
Then all works fine!
If this is only one way to resolve problem with creating permissions then problem is in sqlplus or oracle itself. Sad!
I have this code
BEGIN
UTL_FILE.FREMOVE('DIR_USERS', 'user.jpg');
END;
It raises
ORA-20000: ORA-29291: file remove operation failed
ORA-6412: at "SYS.UTL_FILE", line 251
ORA-6512: at "SYS.UTL_FILE", line 1230
ORA-6512: at "USERS.PKG_USERS", line 177
I think that the error is in the built-in function of the UTL_FILE package because when I used the function UTL_FILE.FRENAME, it also raises the same error.
What could be the problem here?
Does the file exist?
Be aware that UTL_FILE operations are executed at the OS as the user that the oracle processes are running as, usually "oracle". So, does the "oracle" user have rwx privs on the directory containing the file? So "oracle" have rw permission on the file?
The file could be simply hold by another program. I got the same issue:
SQL> begin
2 utl_file.FREMOVE('GK_IMP_KONN_NEW', 'PDT17_2016-05-26T11-32-38');
3 end;
4 /
begin
*
FEHLER in Zeile 1:
ORA-29291: Datei konnte nicht entfernt werden
ORA-06512: in "SYS.UTL_FILE", Zeile 251
ORA-06512: in "SYS.UTL_FILE", Zeile 1230
ORA-06512: in Zeile 2
After uncountable tries I closed the SQL Developer and tried it again:
SQL> begin
2 utl_file.FREMOVE('GK_IMP_KONN_NEW', 'PDT17_2016-05-26T11-32-38');
3 end;
4 /
PL/SQL-Prozedur erfolgreich abgeschlossen.
Success!
We have several Oracle Text indexes of type CTXCAT in our Oracle 11.2.0.3 database.
A process from Oracle Enterprise Manager is running every 8 minutes and dumping errors about an index that hasn't existed in years, like this one in the trace file $ORACLE_HOME/node_SID/sysman/log/emagent.trc:
==================================================================
2013-08-13 05:51:09,882 Thread-1079278176 WARN vpxoci: OCI Error -- ErrorCode(20000): ORA-20000: Oracle Text error:
DRG-10502: index PRODUCTION.IX2_WEB_SESSION_DETAIL does not exist
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_REPORT", line 534
ORA-06512: at line 48
SQL = "/* OracleOEM */
DECLARE
TYPE data_cursor_type IS REF CURSOR;
data_c"...
LOGIN = dbsnmp/<PW>#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node-vip)(PORT=1521))(CONNECT_DATA=(SID=ORCL1)))
2013-08-13 05:51:09,882 Thread-1079278176 ERROR fetchlets.sql: ORA-20000: Oracle Text error:
DRG-10502: index PRODUCTION.IX2_WEB_SESSION_DETAIL does not exist
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_REPORT", line 534
ORA-06512: at line 48
2013-08-13 05:51:09,882 Thread-1079278176 ERROR engine: [rac_database,ORCL,textIndexStats] : nmeegd_GetMetricData failed : ORA-20000: Oracle Text error:
DRG-10502: index PRODUCTION.IX2_WEB_SESSION_DETAIL does not exist
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_REPORT", line 534
ORA-06512: at line 48
2013-08-13 05:51:09,882 Thread-1079278176 WARN collector: <nmecmc.c> Error exit. Error message: ORA-20000: Oracle Text error:
DRG-10502: index PRODUCTION.IX2_WEB_SESSION_DETAIL does not exist
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_REPORT", line 534
ORA-06512: at line 48
==================================================================
I took a wild stab and created a new index by that name of type CONTEXT (CTXCAT didn't work) and the error stopped for a while. I dropped that index, and then started getting the following, which was the same error I saw when I tried creating an index as type CTXCAT:
==================================================================
2013-08-30 02:13:07,129 Thread-1075751520 WARN vpxoci: OCI Error -- ErrorCode(20000): ORA-20000: Oracle Text error:
DRG-11119: operation is not supported by this index type
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_REPORT", line 534
ORA-06512: at line 48
SQL = "/* OracleOEM */
DECLARE
TYPE data_cursor_type IS REF CURSOR;
data_c"...
LOGIN = dbsnmp/<PW>#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node-vip)(PORT=1521))(CONNECT_DATA=(SID=ORCL1)))
2013-08-30 02:13:07,129 Thread-1075751520 ERROR fetchlets.sql: ORA-20000: Oracle Text error:
DRG-11119: operation is not supported by this index type
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_REPORT", line 534
ORA-06512: at line 48
2013-08-30 02:13:07,130 Thread-1075751520 ERROR engine: [rac_database,ORCL,textIndexStats] : nmeegd_GetMetricData failed : ORA-20000: Oracle Text error:
DRG-11119: operation is not supported by this index type
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_REPORT", line 534
ORA-06512: at line 48
2013-08-30 02:13:07,130 Thread-1075751520 WARN collector: <nmecmc.c> Error exit. Error message: ORA-20000: Oracle Text error:
DRG-11119: operation is not supported by this index type
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.CTX_REPORT", line 534
ORA-06512: at line 48
==================================================================
I did some sleuthing and found out that calling ctx_report.index_stats( ctxcat_indexname ) on any CTXCAT type index gave me the exact same error, down to the line numbers.
More sleuthing followed, since looking for textIndexStats on google didn't turn up much. I finally found it in the output list of:
emctl status agent scheduler | grep textIndexStats
But there's nothing in select * from dba_scheduler_jobs matched textIndexStats, so I was unclear where to look next, and would like to know how to prevent a recurrence.
I was able to fix the issue, and decided to answer my own question for others that might run into this problem and hit the same wall I did. I still don't know what caused it, but it is fixed.
Further research pointed me to the following link, which contained enough hints to point me in the right direction. http://docs.oracle.com/cd/B14099_19/manage.1012/b16242/emctl.htm
The section 2.7.6 "Reevaluating Metric Collections" had information on the files that the Enterprise Manager Metrics are stored in. To avoid dead links, I will copy some excerpts of that article here:
1. Go to $ORACLE_HOME/sysman/admin/metadata directory, where $ORACLE_HOME is the Oracle Home of the Management Agent.
2. Locate the XML file for the target type. For example, if you are interested in the host metric 'Filesystem Space Available(%)' metric, look for the host.xml file.
I actually grep'd for textIndexStats in this directory and found it in a file called database.xmlp. I found a lot of information inside the following line:
<Metric NAME="textIndexStats" TYPE="RAW" IS_METRIC_LONG_RUNNING="TRUE" >
The most useful piece of information came from SQL embedded as CDATA, which included the lines:
cursor idx_cur IS
select owner,job_name,comments
from dba_scheduler_jobs where job_name like 'EM_IDX_STAT_JOB%' and
upper(owner) = 'DBSNMP';
idx_rec idx_cur%ROWTYPE;
BEGIN
OPEN idx_cur;
FETCH idx_cur into idx_rec;
guid := :1;
IF idx_cur%FOUND THEN
dbms_lob.createtemporary(statData,false);
dbms_lob.createtemporary(sizeData,false);
dbms_lob.createtemporary(objectsData,false);
idx_name := substr(idx_rec.comments,1,instr(idx_rec.comments,'|')-1);
This makes it obvious that the non-existent index name was being parsed out of a comments column in dba_scheduler_jobs for the DBSNMP user, with a job name like 'EM_IDX_STAT_JOB%'.
Running the same query used in the cursor above showed me a number of records in the scheduler table. Apparently they aren't true scheduler entries but are used to queue this script, which inserts data into sysman.mgmt_text_index_stats. A number of CTXCAT and missing indexes were in the scheduler table. Apparently the rows in the scheduler table are only removed on success, and an incorrect entry will hang around for years.
To fix this issue, I ran the following as user DBSNMP:
BEGIN
for idx_rec in (
select owner,job_name,comments
from dba_scheduler_jobs
where job_name like 'EM_IDX_STAT_JOB%' and upper(owner) = 'DBSNMP')
LOOP
DBMS_SCHEDULER.DROP_JOB( idx_rec.job_name );
END LOOP;
END;
/
This has eliminated the issue of the SPAM'd trace log file. It would be good if CTXCAT indexes could not be added, or that they were handled gracefully when in there. I hope this helps the next DBA down the road, because I spent way too much time on it.