Monday, April 27, 2009
Oracle HTTP Server: EMDAEMON HTTP/1.1 404 , Not Found, when trying to open it with port 80
Stopped Oracle DBConsole services in Windows Services.
Went to:
{drive}:{Oracle_home}\sysman\config\emd.properties
Changed:
# EMD main servlet URL
#
EMD_URL=http://{Your dns name}:/emd/main/
Note the "colon" with missing port number, so this may default to port 80
to:
# EMD main servlet URL
#
EMD_URL=http://{Your dns name}:1830/emd/main/
You may have to use another port besides "1830"
if that is being used by your system.
Rebooted system.
Simply restarting DBConsole services was not enough.
Found that EMAGENT.EXE was no longer listening on IP 0.0.0.0 and Port 80.
Changed Apache to Port 80,
Stopped and restarted Apache.
HTMLDB works on Port 80
and
Oracle Database Control works on Port 1158 (default).
Tuesday, April 21, 2009
Oracle HTTP Server: PERMISSION DENIED: MAKE_SOCK: COULD NOT BIND TO PORT 80
You have to run the following:
1. Log in as root.
2. Run the following commands in the middle-tier Oracle home:
cd ORACLE_HOME/Apache/Apache/bin
chown root .apachectl
chmod 6750 .apachectl
Thursday, March 12, 2009
Tomcat Error: ...is quoted with " which must be escaped when used within the value
ERROR [http-80-Processor22] - Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: /forum/index.jsp(73,36) Attribute value request.getRequestURI()+"?"+request.getQueryString() is quoted with " which must be escaped when used within the value
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:198)
at org.apache.jasper.compiler.Parser.parseQuoted(Parser.java:307)
at org.apache.jasper.compiler.Parser.parseAttributeValue(Parser.java:250)
at org.apache.jasper.compiler.Parser.parseAttribute(Parser.java:211)
at org.apache.jasper.compiler.Parser.parseAttributes(Parser.java:149)
at org.apache.jasper.compiler.Parser.parseParam(Parser.java:875)
at org.apache.jasper.compiler.Parser.parseBody(Parser.java:1829)
at org.apache.jasper.compiler.Parser.parseOptionalBody(Parser.java:1081)
at org.apache.jasper.compiler.Parser.parseInclude(Parser.java:909)
at org.apache.jasper.compiler.Parser.parseStandardAction(Parser.java:1232)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1588)
at org.apache.jasper.compiler.Parser.parse(Parser.java:132)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:212)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:101)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:156)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:296)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:277)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:265)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:302)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.cj.trim.trimFilter.doFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at gr.knowledge.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:121)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Unknown Source)
See the relevant https://issues.apache.org/bugzilla/show_bug.cgi?id=45015
It seems that, you can either edit your jsp code to be more compliant or get rid of the error by editing catalina.properties and putting this extra line:
org.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=falseThis actually tells Tomcat to be more relaxed about JSP compliance regarding double quoted expressions.
See also http://tomcat.apache.org/tomcat-5.5-doc/config/systemprops.html
Monday, March 9, 2009
javax.mail.MessagingException: 501 Syntax: HELO hostname
javax.mail.MessagingException: 501 Syntax: HELO hostname
upon sending an email, most probably you have to set a hostname to the machine running java (not the SMTP server per se)
Run "hostname javaservername " and / or edit /etc/sysconfig/network to note the server name.
Tuesday, March 3, 2009
context XML file deleted when path is not readable
In order to avoid this, edit your server.xml file and set autoDeploy="false" in the Host tag.
See https://issues.apache.org/bugzilla/show_bug.cgi?id=40050
slow login in OpenSSH
UseDNS no
In my case (CentOS 5.2 server, WinSCP/Putty client), this solved the problem, and the connections run REALLY fast now
Monday, February 23, 2009
EXP-00056: ORACLE error 932 encountered ORA-00932: inconsistent datatypes: expected BLOB, CLOB got CHAR
We’re in the middle of converting our 8.1.7.4 database to 10g release 2 (10.2). With this migration we’re also changing the character set of the database to AL32UTF8 and changing the database to char semantics. This gave us serious problems trying to export the database.
First a short introduction on the choice of character set and length semantics: Using Unicode as a character set will allow us to store any character and not just the western European characters we’re currently limited to. Unicode is a multi-byte character set which means that a single character could use more than a single byte. So what do you mean by VARCHAR2(10)
? Is this 10 characters or 10 bytes? This used to be the same with our single byte character set, but these days are over. You can specify VARCHAR2(10 BYTE)
or VARCHAR2(10 CHAR)
if you want to be specific. However, all of our existing code doesn’t use this syntax. This is where the NLS_LENGTH_SEMANTICS
parameter comes in. You can set this to BYTE or CHAR basically defining which one of the two is the default when not specifying it explicitly. A default installation will use BYTE semantics, but we decided to change it to CHAR. To me that is the more logical option.
So, we created a fresh database with NLS_LENGTH_SEMANTICS=CHAR
. If you then run an export:
C:\>set ORACLE_SID=dev01
C:\>set NLS_LANG=AMERICAN_AMERICA.AL32UTF8
C:\>exp '/ as sysdba' full=y file=full.dmp
Export: Release 10.2.0.1.0 - Production on Tue Nov 22 09:48:06
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Personal Oracle Database 10g Release 10.2.0.1.0
With the Partitioning, OLAP and Data Mining options
Export done in AL32UTF8 character set and AL16UTF16 NCHAR
character set
About to export the entire database ...
. exporting tablespace definitions
. exporting profiles
. exporting user definitions
. exporting roles
. exporting resource costs
. exporting rollback segment definitions
. exporting database links
. exporting sequence numbers
. exporting directory aliases
. exporting context namespaces
. exporting foreign function library names
. exporting PUBLIC type synonyms
. exporting private type synonyms
. exporting object type definitions
. exporting system procedural objects and actions
. exporting pre-schema procedural objects and actions
. exporting cluster definitions
EXP-00056: ORACLE error 932 encountered
ORA-00932: inconsistent datatypes: expected BLOB, CLOB got CHAR
EXP-00056: ORACLE error 932 encountered
ORA-00932: inconsistent datatypes: expected BLOB, CLOB got CHAR
EXP-00000: Export terminated unsuccessfully
Searching MetaLink made me find Note 339938.1 which describes a situation where a 10.2 full export fails with an ORA-932 when exporting the cluster definitions. I figured I found the issue and a solution. But the note describes that some SYS objects should be invalid whereas all my SYS objects are valid. It also describes that a SELECT on sys.ku$_xmlschema_view should fail. This one does fail on me:
SQL> select url, local, stripped_val from sys.ku$_xmlschema_view;
select url, local, stripped_val from sys.ku$_xmlschema_view
*
ERROR at line 1:
ORA-00932: inconsistent datatypes: expected BLOB, CLOB got CHAR
Now it was time to open a Service Request (the new name for a TAR) on MetaLink. In the end the support engineer came with the solution. It all boiled down to two pieces of advice:
- only switch to char semantics after database creation (that has no impact on the “char semantics support”, any SYS objects cannot be CHAR and that is what happened here)
- use a “startup migrate” when running any patch or catalog scripts
So I shouldn’t have set NLS_LENGTH_SEMANTICS=CHAR before creating the database. The second advice to always use STARTUP MIGRATE is also a good tip. This will force the system of doing anything in byte semantics.
Here are the steps to “repair” my database. First check that the NLS_LENGTH_SEMANTICS is indeed set to CHAR. Then shutdown the database and restart as “startup migrate” You can see that the length semantics are now BYTE:
C:\>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Nov 22 10:00:46
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Personal Oracle Database 10g Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> column parameter format a20
SQL> column value format a5
SQL> select * from nls_session_parameters
2 where PARAMETER='NLS_LENGTH_SEMANTICS';
PARAMETER VALUE
-------------------- -----
NLS_LENGTH_SEMANTICS CHAR
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup migrate;
ORACLE instance started.
Total System Global Area 469762048 bytes
Fixed Size 1249608 bytes
Variable Size 146804408 bytes
Database Buffers 314572800 bytes
Redo Buffers 7135232 bytes
Database mounted.
Database opened.
SQL> select * from nls_session_parameters
2 where PARAMETER='NLS_LENGTH_SEMANTICS';
PARAMETER VALUE
-------------------- -----
NLS_LENGTH_SEMANTICS BYTE
Now drop the XML DB stuff. After that exit SQL*Plus. There is some bug that screws up your session. This means you’ll have to close SQL*Plus at the end:
SQL> @?\RDBMS\ADMIN\catnoqm.sql
PL/SQL procedure successfully completed.
User dropped.
PL/SQL procedure successfully completed.
Table dropped.
SQL> exit
ERROR:
ORA-00600: internal error code, arguments: [729], [256],
[space leak], [], [], [], [], []
Disconnected from Personal Oracle Database 10g Release 10.2.0.1.0
With the Partitioning, OLAP and Data Mining options
(with complications)
There is a bug that says you have to restart the database after running catnoqm. Be sure to start it with “startup migrate” again:
C:\>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Nov 22 10:05:17
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Personal Oracle Database 10g Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup migrate;
ORACLE instance started.
Total System Global Area 469762048 bytes
Fixed Size 1249608 bytes
Variable Size 146804408 bytes
Database Buffers 314572800 bytes
Redo Buffers 7135232 bytes
Database mounted.
Database opened.
SQL> column parameter format a20
SQL> column value format a5
SQL> select * from nls_session_parameters
2 where PARAMETER='NLS_LENGTH_SEMANTICS';
PARAMETER VALUE
-------------------- -----
NLS_LENGTH_SEMANTICS BYTE
Now run the CATQM.SQL script which requires three arguments (initial password and two tablespaces):
SQL> @?\RDBMS\ADMIN\catqm.sql change_on_install SYSAUX TEMP
Table created.
Table created.
[[ lot of succesfull statements removed for readability ]]
Package dropped.
Package dropped.
Function dropped.
Commit complete.
Now shutdown and start the database normally. You can check that the length semantics are back to its original (CHAR) and the query from sys.ku$_xmlschema_view now works fine:
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 469762048 bytes
Fixed Size 1249608 bytes
Variable Size 150998712 bytes
Database Buffers 310378496 bytes
Redo Buffers 7135232 bytes
Database mounted.
Database opened.
SQL> column parameter format a20
SQL> column value format a5
SQL> select * from nls_session_parameters
2 where PARAMETER='NLS_LENGTH_SEMANTICS';
PARAMETER VALUE
-------------------- -----
NLS_LENGTH_SEMANTICS CHAR
SQL> select url, local, stripped_val
2 from sys.ku$_xmlschema_view;
URL
----------------------------------------------------------------
LOCAL
----------
STRIPPED_VAL
----------------------------------------------------------------
http://xmlns.oracle.com/xdb/XDBSchema.xsd
0MetaLink Note 144808.1 for more information and limits of using BYTE and CHAR semantics. This case will be added to this Note. Update 17-dec-2005: Oracle filed bug 4886376 to have this problem fixed in a future release. The bug description also indicates that AL32UTF8 will be the default character set for a version 11.x database.