Database: 10.2.0.2, Apex 3.2.1. Application works fine, until there's a bit of load of users logging in. They get the following message (derived from error-logging of Apache): [Wed Mar 10 09:21:58 2010] [error] [client 127.0.0.1] [ecid: 1268209318:220.127.116.11:1543:0:26453,0] mod_plsql: /pls/apex_app/wwv_flow.accept HTTP-404 ORA-06550: line 22, column 3:PLS-00306: wrong number or types of arguments in call to 'ACCEPT' ORA-06550: line 22, column 3:PLS-00306: wrong number or types of arguments in call to 'ACCEPT' ORA-06550: line 22, column 3:PL/SQL: Statement ignored
Got errors (ora-03114 / ora-03113) while running any dbms_java script on a 10.2.0.2 database. Took a while, but then I found out it only happens when I'm connected through sql*net. Directly on the server gave no problem at all. And... it only occurs on my Test-environment, not in development, and not in production.
After "alter table DWHINCIDENT.TEST_TABLE drop unused columns checkpoint 100000" And after a while: ERROR at line 1: ORA-00600: internal error code, arguments: , [0x12CB1C820], , , , Table in usable state. New bug !
Installed 11g release 2 , and wanted it to start and stop when booting and stopping the system. Taking into consideration that most of the standard stop-scripts are causing the database to 'crash' without knowing it.
Something about running statistics. Got quite a large database of a few TB, and was curious how fast the statistics are running, and if I could speed it up a little.
I had to install a 11g release 1 on Windows for demonstration purpose of APEX. APEX comes standard with 11g, so that's nice. When using Embedded PLSQL you don't even need Apache... But when I'm using http://localhost:8080/apex/apex_admin, the login-page popped up after a minute or two.And every page I use has the same horrible performance. Using the loopback by the way like http://127.0.0.1:8080/apex/apex_admin on the server gives the same result.
Working on 11g, release 1 (18.104.22.168), managers wanted to know what kind of compression factor we achieved in the datawarehouse. Amount of (compressed) data: just about 1,5 TB. In all my naivity I thought Oracle delivered the package 'DBMS_COMPRESSION' which will show me the rate of achieved compression per table. But first of all, in 11gr1 there was no package like 'DBMS_COMPRESSION', this is only delivered with release 2.