ORA-39083: Object type ROLE_GRANT failed to create with error:

I got this error when I was trying to do a full import of a dump file.

$ impdp "'/ as sysdba'" full=y directory=data_pump_dir dumpfile=fullexport.dmp logfile=fullimport.log

Import: Release 11.2.0.1.0 - Production on Sat Aug 7 01:02:52 2010

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01": "/******** AS SYSDBA" full=y directory=data_pump_dir dumpfile=fullexport.dmp logfile=fullimport.log
Processing object type SCHEMA_EXPORT/ROLE_GRANT
ORA-39083: Object type ROLE_GRANT failed to create with error:
ORA-01919: role 'QUALYS_ROLE' does not exist
Failing sql is:
GRANT "QUALYS_ROLE" TO "SYS" WITH ADMIN OPTION

Job "SYS"."SYS_IMPORT_FULL_01" completed with 1 error(s) at 01:03:06


I checked the dump file and it was only 141 KB in size. Then I checked the export log file and realized that I had forgotten to put full=y while doing expdp. So it was just a schema export of SYS and did not have the full database.

Once I realized this and took an export with expdp full=y command, the import completed successfully.

ORA-28000: the account is locked at OCI call OCISessionBegin

If you ever get this error in OTM/FTI Transportation Intelligence screens:

State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 17001] Oracle Error code: 28000, message: ORA-28000: the account is locked at OCI call OCISessionBegin. [nQSError: 17014] Could not connect to Oracle database. (HY000)

Your HDOWNER user is locked out at database stage. Unlock the user

Login as the unix owner of ROD database. Make sure your ORACLE_HOME and other environment variables are set correctly.

sqlplus /nolog
conn / as sysdba
alter user HDOWNER account unlock;

Zebra printer and pasta driver

Shiva described a Zebra printer issue to me. They had configured Zebra007 printer on Dev and Test, and it printed fine. However when the same printer was configured on Production instance, it did not print anything. I worked with Puneet and Sateesh to check the windows printer queue. Whenever a print job was executed in Dev or Test (non-Production) instances, the label printed correctly. However when they tried to print from Production, it would not print anything, though a pasta*.tmp appeared in windows printer queue for 2 seconds.

I also got a sample file example.zpl from Sateesh to find out the contents, This file was a plain text file which contained print control characters. This is an ingenious way to print without installing expensive proprietary drivers from vendors. If such a file is sent as a raw file to printer, the printer interprets the special characters and prints labels correctly. So they were using Pasta printing to print a text file. This didn't make sense, as pasta is typically used to convert (preprocess) pdf files generated by XML Publisher (now known as BI Publisher) into postscript format and send to printer.

I examined the $FND_TOP/resource/pasta.cfg in Production and non-Production instances. They were different. Non-production pasta files had everything commented, whereas Production pasta file had this entry:

$ cd $FND_TOP/resource
$ cat pasta.cfg
/* $Header: pasta.cfg 115.23 2003/03/28 22:57:31 mnagakur noship $ */

[DEFAULT]

preprocess=/usr/local/bin/pdf2ps {infile} {outfile}
printCommand=lp -c -d{printername}
errorlogfile=pasta_pdf2.log

I realized then that, the printing was successful in development, as pasta was not doing any kind of preprocessing and printing the file. It failed in Production because the text file containing printer commands was going through preprocessing:

/usr/local/bin/pdf2ps example.zpl pasta8282.ps

Error: /undefined in .CT~~CD,~CC^~CT~
Operand stack:

Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
--dict:1129/1686(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)--
Current allocation mode is local
Current file position is 17
GPL Ghostscript 8.54: Unrecoverable error, exit code 1

The solution was to create a new pasta driver pasta_zebra.cfg where the preprocess line would be commented:

$ cat pasta_zebra.cfg
/* $Header: pasta.cfg 115.23 2003/03/28 22:57:31 mnagakur noship $ */

[DEFAULT]

; preprocess=/usr/local/bin/pdf2ps {infile} {outfile}
printCommand=lp -c -d{printername}
errorlogfile=pasta_pdf.log

I tested this on commandline with this command:

FNDPSTAX -pnZebra007 -f/tmp/example.zpl -c1 -Fpasta_zebra.cfg

And it printed the first correct label from Production instance.

This command would be the final result of the printing inside E-Business Suite.

connect / as sysdba ORA-01031 Insufficient privileges

On a freshly installed 11gR2 Oracle Database, I set the following environment variables:

ORACLE_BASE
ORACLE_HOME
ORACLE_SID
TNS_ADMIN
TWO_TASK
LD_LIBRARY_PATH

However when I tried to connect to it:

sqlplus /nolog
conn / as sysdba
ORA-1031 Insufficient Privileges

A search on My Oracle Support showed this:

Error: ORA 1031
Text: insufficient privileges
-------------------------------------------------------------------------------
Cause: An attempt was made to change the current username or password without
the appropriate privilege. This error also occurs if attempting to
UPDATE a table with only SELECT privileges, if attempting to CONNECT
INTERNAL, or if attempting to install a database without the necessary
operating system privileges.
Action: Ask the database administrator to perform the operation or grant the
required privileges.

However I got my answer from this article:

UNIX: Checklist for Resolving Connect AS SYSDBA Issues [ID 69642.1]

It turned out that unsetting the environment variable TWO_TASK resolved the issue:

unset TWO_TASK
sqlplus /nolog
conn / as sysdba
Connected.