head over to the blog of dbi services to read the full article:
Archives For ouch!
head over to the blog of dbi services to read the full article:
if you do a solaris 10u11 core/minimal installation and after that add all packages listed in the documentation the oracle database 12.1.0.2 software installation will fail with:
WARNING: Verification of target environment returned with errors. WARNING: [WARNING] [INS-13001] Environment does not meet minimum requirements. CAUSE: Minimum requirements were not met for this environment ACTION: Either check the logs for more information or check the supported configurations for this product.. Refer associated stacktrace #oracle.install.commons.util.exception.DefaultErrorAdvisor:339 INFO: Advice is CONTINUE WARNING: Advised to ignore target environment verification errors. INFO: Verifying setup for installer validations INFO: Overall status of CVU API call:OPERATION_FAILED SEVERE: [FATAL] [INS-30131] Initial setup required for the execution of installer validations failed. CAUSE: Failed to access the temporary location. ACTION: Ensure that the current user has required permissions to access the temporary location.
this is a bit misleading. the real cause of this (at least in my case) are missing packages:
SUNWpool SUNWpoolr
once these are installed the installation will succeed.
some days ago we tried to remove a trusted certificate from an oracle wallet and this throwed “improperly specified input name”.
test-case:
Download the certificate from this website
create the wallet:
orapki wallet create -wallet . -pwd "Oracle1"
add the certificate to the wallet:
orapki wallet add -wallet . -cert a.pem -trusted_cert -pwd "Welcome1"
then try to remove it:
orapki wallet remove -wallet . -dn 'CN=www.cenduitsolutions.com,OU=Cenduit LLC,O=Cenduit LLC,L=Durham,ST=North Carolina,C=US,2.5.4.17=27703,STREET=4825 Creekstone Drive,STREET=Suite 400,SERIAL_NUM=4312751,1.3.6.1.4.1.311.60.2.1.2=Delaware,1.3.6.1.4.1.311.60.2.1.3=US,2.5.4.15=Private Organization' -trusted_cert -pwd "Welcome1" Oracle PKI Tool : Version 12.1.0.2 Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. improperly specified input name: CN=www.cenduitsolutions.com,OU=Cenduit LLC,O=Cenduit LLC,L=Durham,ST=North Carolina,C=US,2.5.4.17=27703,STREET=4825 Creekstone Drive,STREET=Suite 400,SERIAL_NUM=4312751,1.3.6.1.4.1.311.60.2.1.2=Delaware,1.3.6.1.4.1.311.60.2.1.3=US,2.5.4.15=Private Organization
turned out that this is because of oracle bug (13773007) which seems to be there since 11gR1 although the error message is slightly different. only certificates for which “the DN includes a serial number attribute” seem to be affected.
the workaround is to do it this way:
orapki wallet remove -wallet . -alias 'CN=www.cenduitsolutions.com' -trusted_cert -pwd "Welcome1"Oracle PKI Tool : Version 12.1.0.2 Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved.
surprisingly the “-alias” switch seems not to be documented or least is not listed in the orapki help output.
11.2.0.4 on Linux x64:
alter system flush shared_pool; drop table t1; create table t1 as select 'grant sysdba to me' a from dual; set long 20000 select sql_id,sql_fulltext from v$sql where sql_text like 'create table t1%'; select sql_id,sql_fulltext from v$sqlarea where sql_text like 'create table t1%'; desc t1
result:
SQL_ID SQL_FULLTEXT ------------- -------------------------------------------------------------------------------- dbgtudsa7v0wj create table t1 as s SQL_ID SQL_FULLTEXT ------------- -------------------------------------------------------------------------------- dbgtudsa7v0wj create table t1 as s
at least there is a fix for it (19148376) if you are willing to install psu1 on top of 11.2.0.4 (which is a prereq).
today, on an upgraded asm/gi instance from 11.2.0.4 to 12.1.0.2 on linux x64 we faced the following situation (although the upgrade went smooth and everything was up and running):
srvctl config asm ASM home: PRCA-1057 : Failed to retrieve the password file location used by ASM asm PRCR-1097 : Resource attribute not found: PWFILE
in 11.2.0.4 the attribute for the asm password files was not available:
srvctl modify asm -h
Modifies the configuration for ASM.
Usage: srvctl modify asm [-l ]
-l Listener name
-h Print usage
this came in 12.1.0.1 (together with other attributes):
srvctl modify asm -h
Modifies the configuration for ASM.
Usage: srvctl modify asm [-listener ] [-spfile ] [-pwfile ] [-diskstring ]
-listener Listener name
-spfile Server parameter file path
-pwfile Password file path
-diskstring ASM diskgroup discovery string
-help Print usage
seems easy to fix:
srvctl modify asm -pwfile [SOME_PATH]/orapw+ASM PRCR-1097 : Resource attribute not found: CARDINALITY
no way to get the password file attribute into the GI. the workaround is to stop the complete GI, remove the ASM resource and then add it in again providing all the parameters. makes fun on a production host :)
mos note: 1935891.1
another ouch with the grid infrastructure (tested with 12.1.0.2). steps to reproduce:
1. configure the GI on the first node
2. deconfigure the GI on the first node ( rootcrs.pl -deconfig -force )
3. change the network configuration (ip address) for the privat interconnect
4. configure the GI again => this will fail
the reason is that “rootcrs.pl -deconfig -force” does not delete the gpnp profile. to fix this just delete the profile:
rm -rf [GI_HOME]/gpnp/[NODE_NAME]/
This is somehow documented in mos note 942166.1
do not apply PSU 12.1.0.1.4 if you are using APEX and the embedded plsql gateway: you might hit bug 18610915 which is internal and therefore no description is available.
if you hit this you are either not able to even bring up the apex login page (neither http nor https) or it stops working after a few connections (dispatchers are dying).
path “Patch 18610915: INTERMITTENT SEGMENTATION FAULT DURING NZ/PRNG INIT” is only available for 12.1.0.2.
tested on 11.2.0.4 and 12.1.0.1 on Linux x64:
#!/bin/bash
SQLFILE=/var/tmp/subqueries.sql
echo "select * from ( " > ${SQLFILE}
for x in {1..100000}
do
if [ $x == "100000" ]; then
echo "select * from dual )" >> ${SQLFILE}
else
echo " select * from ( " >> ${SQLFILE}
fi
done
for x in {1..99999}
do
echo ")" >> ${SQLFILE}
done
execute the generated /var/tmp/subqueries.sql script:
@/var/tmp/subqueries.sql 200001 ; select * from ( * ERROR at line 1: ORA-03113: end-of-file on communication channel Process ID: 21287 Session ID: 34 Serial number: 2369
I do not say, that using 100000 subqueries is in any way useful :)
maybe this is not related to the amount of subqueries but rather to the number of lines or the number of characters in the statement. did not test this.
Daniel Westermann's Blog 