“The web application at (URL) cannot be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.”

This despite the fact that I had created the destination site specified by the URL. I also performed the import from the destination server.

This was resolved after I registered my Windows account (which I used to log on to the destination server) as one of the SharePoint farm administrators (done using SharePoint central administration page). It is not enough to log on using the account that created the destination site

RMAN> restore controlfile from autobackup maxseq 200 maxdays 500;

Starting restore at 21-oct-08 14:58
using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 10/21/2008 14:58:42
RMAN-06494: MAXDAYS = 500 is out of range (1-366)

So how to restore spfile and control file from a backup taken more than 366 days ago? I found that when RMAN performs restore from autobackup file, it did not check the timestamp of the autobackup file but the timestamp that is stated in the autobackup file name. By changing the autobackup file name so that the timestamp is within the accepted range, it can find and read the autobackup file and restore the controlfile / spfile successfully.

Without the maxdays option, RMAN will only look for autobackup file with timestamp within the last 7 days. So if today is 22 Oct 08 and your autobackup file name in $ORACLE_HOME/dbs is “c-1154185322-20081012-01″, the “restore controlfile from autobackup” command will not be able to find or read the autobackup file.

Change it to “c-1154185322-20081021-01″ and RMAN will be able to restore the control file from autobackup with “restore controlfile from autobackup” command. I don’t have a controlfile autobackup created more than 366 days ago, but I think this trick can also address 366-maxdays limitation.

SQL> CREATE OR REPLACE VIEW DBA_USERS_V
AS SELECT * FROM DBA_USERS;
 FROM DBA_USERS
      *
ERROR at line 3:
ORA-00942: table or view does not exist
If SELECT ANY DICTIONARY is not available for the database (like 8.0.5, 8.1.6, 8.1.7), grant SELECT privilege to the user directly using SYS user.

SQL> CONN / AS SYSDBA
SQL> GRANT SELECT ON DBA_USERS TO AUDITUSER;

SQL> CONN AUDITUSER
SQL> CREATE OR REPLACE VIEW DBA_USERS_V
AS SELECT * FROM DBA_USERS;

View created.

SQL> create materialized view db2_dba_ts_quotas_mv
 build immediate
 refresh with rowid complete on demand
 as select tablespace_name, username, max_bytes
 from dba_ts_quotas@db1;

ERROR at line 1:
ORA-00942: table or view does not exist
ORA-06512: at “SYS.DBMS_SNAPSHOT_UTL”, line 1543
ORA-06512: at line 1

The user used in the database link has SELECT ANY DICTIONARY access in the remote database.

Creation of the same materialized views for other 10.2.0.4 database works. To address this issue, instead of creating materialized view based on sys.dba_ts_quotas, I created a view for sys.dba_ts_quotas for the db link user, and create the materialized view based on this view. It worked fine!

Error message:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
SVR4 Error: 2: No such file or directory

From the db server itself, I was able to connect to the database using OS authentication.
When I run ps -ef, I found that the background process are all using ORACLE instead of “oracle”

oracledb 22187     1  0 10:22:16 ?        0:02 ora_smon_ORACLE
oracledb 22189     1  0 10:22:16 ?        0:00 ora_reco_ORACLE
oracledb 22191     1  0 10:22:16 ?        0:01 ora_cjq0_ORACLE
oracledb 22199     1  0 10:22:17 ?        0:00 ora_p000_ORACLE
oracledb 22181     1  0 10:22:16 ?        0:00 ora_dbw0_ORACLE
oracledb 22179     1  0 10:22:16 ?        0:00 ora_mman_ORACLE
oracledb 22203     1  0 10:22:17 ?        0:00 ora_p002_ORACLE
oracledb 22185     1  0 10:22:16 ?        0:01 ora_ckpt_ORACLE

The listener name was “oracle”. To fix the connection problem, shutdown the listener, edit listener.ora and change occurrence of “oracle” to “ORACLE”. Restart the listener.
Test connection from SQL*Plus on PC client again.

• db_block_size – the bigger the block size, the less disk I/O
• db_cache_size – the bigger the buffer cache, the less need to perform disk I/O