ReCreate my Database

Hi,
I have a production Oracle 8i Database, but it support only US7ASCII character set.
I would like to configure my Database to support uncode character set.
thank you for your time.

Hello,
It seems that you used a third-part tool Backup Exec 11D to backup SQL Server database.
Since it is related to third-part tool, I suggest you ask the software vendor for support. Or you can post the question and error message you received in the
Symantec support community.
Regards,
Fanny Liu
Fanny Liu
TechNet Community Support

Similar Messages

How to recreate the database only?

Hi All,
We are having some dictionary blocks corrupted in our application database. The solution is to recreate the database and import the whole database into this new database. Details of product we are having
OS : RHEL- ES 3
Application : 11.5.9
Database : 11.2.0.3
Now our main consideration is:
1) How to recreate the database without reinstalling the applications.
2) Is there any special consideration to follow?
3) What will be the impact of recreation of database on Applications?
Pls help me in this matter.
Thanks and Regards
Amit Raghuvanshi

You can use the above command to just install the Oracle Home in a new path.
But, i am not sure if export / import works or not. May be other experts can comment on this.
If you have a physical backup, it would be better to clone the db rather than Export / import.

Recreating a database manually

Hi,
I have a database and a full import does not work well. So the suggestion was to recreate the database. To recreate the database manually I deleted first: datafiles, control files, archive, redo log. I forgot to shutdown. Now if I want to startup in nomount to run the script for manually creating the database is necessary to have control files (which were deleted).
What to do?
Thank you,
Mihaela

Check the udump directory, if it is still around. If you executed an 'alter database backup controlfile to trace' any time recently, you will have a trace file that contains everything you need to rebuild the control file. Also check bdump for the alert log. When you start the database, the parameters that are set to nondefault values are recorded in the alert log. You can recreate an init.ora file with those values to use when you create your database.
One option is to create a simple database, create the user that owns the schema, and try the import to bring the database in. Best of luck in recovering.

Recreation of database

Hi All,
We have corrupted blocks in sys schema for which metalink has suggested recreation of database through IMPORT utility. We are having front end applications running on the database .... now we want to recreate the database exactly same as the one previously there. Does there any special consideration.
Our OS is RHEL ES3
Database is 9.2.0.3
Thanks and Regards
Amit Raghuvanshi

Are you running on archivelog and have a valid rman backup?
Block recover feature may help you withour any downtime and with a very little effort compared to imp - http://download.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmconc2.htm#459496
SQL> select * from emp;
select * from emp
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 24165)
ORA-01110: data file 4: ‘D:\ORACLE\ORADATA\USERS01.DBF’
SQL> select header_file,header_block from dba_segments where segment_name=’EMP’;
HEADER_FILE HEADER_BLOCK
4 24163
SQL> select * from v$backup_corruption;
RECID STAMP SET_STAMP SET_COUNT PIECE# FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# MAR CO
1 550688483 550688389 46 1 4 24165 1 0 YES CORRUPT
The above output confirms that block 24165 in file 4 is indeed corrupt. We can recover the same using the following command.
RMAN> run {blockrecover datafile 4 block 24165;}
Starting blockrecover at 25-OCT-06
using channel ORA_DISK_1
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00004
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=D:\ORACLE\FLASH_RECOVERY_AREA\BACKUPSET\2005_02_19\O1_MF_NNNDF_TAG20050219T164615_11FNO9BQ_.BKP tag=TAG20050219T164615
channel ORA_DISK_1: block restore complete
starting media recovery
media recovery complete
Finished blockrecover at 25-OCT-06
SQL> select * from emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
7369 SMITH CLERK 7902 17-DEC-80 800 20
14 rows selected.
Best regards.

Recreating the database on a different server-NOCATALOG

Hi
I've the following scenario.
I'm taking the RMAN backup of my database using NOCATALOG. Due to some hardware failure I lost the server and now I've only the RMAN backup copies with me. I want to restore the database on a different new server. Can someone provide me the steps for doing so.
Thanks
Balaji

RMAN Restore database NOCATALOG on a different server
rman nocatalog target=/
RMAN> startup nomount
RMAN> set dbid 2438346378;
RMAN> restore controlfile from '/u103/data/ASAP/ASAPTST/c-2438346378-20070212-0';
RMAN> startup mount
RMAN> restore database;
RMAN> recover database;
RMAN> alter database open;
RMAN> alter database open resetlogs;

RECREATE DATABASE Using CONTROL File After SUSPEND Database

Hello All,
Does someone can tell me if he does achieve recreating a database using "Backup Control File" after putting database in "suspend" mode?
The procedure looks like this :
1 - Alter DATABASE Suspend
2 - A Snapshot of the filesystem where the oracle datafile are located
3 - Copy of those files to another file systeme
4 - Startup setting a new database name
Does someone as do it successfully ?
Thanks for your answer

Carlos,
I tried to do it without putting the tablespaces in backup mode and it didn't work for me. At that time adding the backup mode wasn't a big deal for me, so I didn't investigate the problem thoroughly.
Logically thinking you sould be able to do:
1. suspend database
the SCNs recored in datafiles headers could be incosistent at this point
2. make a snapshot
3. mount the backup database
4. run recover until cancel using backup controlfile - I don't think you can avoid this step in case if you have inconsistent SCNs in the datafiles headers - you'll need to synchronize them
5. open resetlogs.
the suspend database should eliminate the possibility of inconsistent data within a block during the backup.
Just out of curiosity - why don't you want to put the tablespace in the backup mode?
Mike

Script for dropping aand recreating Database

Please someone tell me that dropping a database in Cluster environment is same as in standalone server? Please let me know asap. If someone know how I would recreate the same database. Thnx

The best way to recreate the database is using te DBCA. In case you are doing it manualy then it depends on:
Case 1:
The ORACLE_HOME and name of the database being created is same as of the database being dropped
- Drop the database (don't delete the init.ora file as you can reuse this if everything is going to be same for the new database)
- Recreate the database or contolfile for the new database.
Case 2:
The ORACLE_HOME and name of the database being created is diferent as of the database being dropped
- Drop the database
- Remove the database from the Oracle Cluster Registry using SRVCTL command.
- Recreate the database or contolfile for the new database.
- Register the database in Oracle Cluster Registry using SRVCTL
Thanks & Regards

Dropped database, attempt to recreate it fails

Previously I inadvertently created a TEST database with objects in the SYSTEM tablespace so I removed all trace of that database by deleting all the files associated with it (control, rollback, temp, user, redo, data).
Now I'm trying to recreate the database from scratch but it's failing with "ORA-01092: ORACLE instance terminated. Disconnection forced".
My create statement is (almost certainly more complex than absolutely necessary):
create database test datafile '$ORACLE_HOME/dbs/test/testdata01.dbf' size 20m reuse extent management local
logfile group 1 ('$ORACLE_HOME/dbs/test/testredo01.log') size 10m, group 2 ('$ORACLE_HOME/dbs/test/testredo02.log') size 10m
default temporary tablespace testtemp tempfile '$ORACLE_HOME/dbs/test/testtemp01.dbf' size 20m reuse
undo tablespace testundo datafile '$ORACLE_HOME/dbs/test/testundo01.dbf' size 40m reuse autoextend on next 5120k maxsize unlimited;
I've specified AUTO for undo_management in my ORA file. I was hoping that it would make my life simpler.
I suspect that some remnant of my old database exists and its preventing the new database being created. Any ideas what it could be? Or where to look?
PS I previously had remote login to the old database via an orapwd password file but that file has also been deleted.

Thanks for checking Joel. I think we've resolved the underlying problem.
I found a log file that indicated that the 'compatible' setting in my init<sid>.ora file was wrong. It would have been nice for the create database call to tell me that rather than "ORA-01092: ORACLE instance terminated. Disconnection forced" but, in its defence, maybe it can't.
Also, it would have been nice if it had deleted all the files that it created during the failed database creation attempt. I can understand that Oracle don't typically delete datafiles but this is surely the one situation in which they can definitely do so safely -- Oracle just created them after all so it must know that it's safe to delete them. Plus for a product that supports the notion of all or nothing transactions, you'd have thought it was a given ;-)
Anyhow, I had no explicit 'compatible' setting in init<sid>.ora so it must have defaulted to something other than 9.2.0. This is a little strange, because previously I had no setting either yet I was able to create a database. Perhaps I recently enabled some 9i-specific feature that forced me to set compatible to 9.2.0? Not quite sure.
Bottom line is that it's alive and I've even inserted 3 records into my new table. Woohoo. And my three records only take up 100Mb ;-)

Recreating database with backups on a different server

Dear buddies,
I am backing up with RMAN
Level 0 backup on Sundays and Level 1 backup on weekdays
Now, I want to recreate this database on another server.
Is it possible? I do not want to do duplicate or cloning.
Any suggestions?
What do we call this kind of recovery?
Should I be doing something like this?
Make a full backup all of current your database files instead of using the Level 0 or Level 1 backups.
Place all database files to same directories.
Create the Windows service if removed.
C:\> oradim.exe -new -sid <ORACLE_SID> -startmode -manual
Startup instance.
C:\> net start OracleService<ORACLE_SID>
C:\> sqlplus /nolog
SQL> connect / as sysdbaThanks!

you are going in right direction .Check the below link this may help you
http://neeraj-dba.blogspot.com/2011/05/complete-loss-of-all-oracle-datafiles.html
--neeraj

Recreating database where repository is located

Do to the way a database was migrated from one server to another i need to recreate a database to remove internal references to the old server. this database contains the owb repository. i am planning to take a full export, drop the database, recreate the database and do an import.
is anyone aware of any issues with this? ...i.e. dbid stored somewhere in the repository?

well...things didn't go as planned.
datapump errored out when i did a full export with the following:
ORA-39125: Worker unexpected fatal error in KUPW$WORKER.UNLOAD_METADATA while calling DBMS_METADATA.FETCH_XML_CLOB [PROCOBJ:"STRAIN"."STRAIN_OPT_INDEX_JOB"]
ORA-22813: operand value exceeds system limits
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 105
ORA-06512: at "SYS.KUPW$WORKER", line 6241
----- PL/SQL Call Stack -----
object line object
handle number name
0x17adf6b50 14916 package body SYS.KUPW$WORKER
0x17adf6b50 6300 package body SYS.KUPW$WORKER
0x17adf6b50 2340 package body SYS.KUPW$WORKER
0x17adf6b50 6861 package body SYS.KUPW$WORKER
0x17adf6b50 1262 package body SYS.KUPW$WORKER
0x17adab5f0 2 anonymous block
Job "SYSTEM"."WATCH" stopped due to fatal error at 16:46:50
...i've got a tar open on this but can't proceed without a full export!
let me know how your attempt goes.
thanks.

Recreate database from XML - what will I loose?

I have run into a problem where the database contains incorrect information about the location of some files. I could do an easy search and replace for all the occurences, but if I recreate the database as Apple suggests http://docs.info.apple.com/article.html?artnum=93313 - what will I loose?

I have run into a problem where the database contains incorrect information about the location of some files.
Following that article will not fix the location of those files.
Try this -> Bring Out Yer Dead v1.1
or this -> iTunes Track CPR v1.3

Application pages gone after database destroy / recreate / import

Hi -- Our DBA had to completely recreate the database in
which our APEX installation lives.
What he did was:
- exported the DB
- destroyed the DB
- recreated the DB
- reinstalled APEX
- full database import
Workspaces are there. Applications are there. Application shared objects are there.
But none of the applications have any pages.
Any idea what's up, how to fix it?
thanks!
Carol

HI Scott - Yes, unfortunately, it's still a problem. The DBA said that after the initial database import, there were no grants for objects owned by SYS. When he tried to login to the admin area of APEX, he got these errors (recorded in the Apache error logs):
Tue Aug 12 09:29:20 2008] [error] [client 127.0.0.1] [ecid: 1218554959:140.217.14.12:23313:0:1,0] mod_plsql: /pls/apex/apex HTTP-404 ORA-04063: package body "FLOWS_030000.WWV_FLOW_SECURITY" has errors\nORA-06508: PL/SQL: could not find program unit being called: "FLOWS_030000.WWV_FLOW_SECURITY"\nORA-06512: at "FLOWS_030000.APEX", line 1\nORA-06512: at line 22\n
[Tue Aug 12 09:16:05 2008] [error] [client 127.0.0.1] [ecid: 1218554165:140.217.14.12:24745:0:15,0] File does not exist: /ora/oracle/product/10.2.0/http_1/Apache/Apache/htdocs/favicon.ico
Our DBA had found something about this problem with respect to APEX 2. He wasn't sure if it applied to APEX 3, but re-installing APEX corrected the problem.
Thanks,
Carol

Recreate database

i have full backup.
I performaed following thing to recreate my database again.
1)created new dir str with pfile(Dir str is not same)
2)created new services and paswword file (same as privious one)
3)start database in nomount with pfile.
4)restore the control file from backup.
5)alter database in mount state.
6)restore the backup with following command .
rman target /
rman >run
set newname for datafile 1 to '' ;----->path of new file location
set newname for datafile 2 to '' ;
set newname for datafile 3 to '' ;
restore database;
switch datafile all;
7)alter database open resetlogs;
now it is giving the following error
ora:01152 file 1 was not restored from a sufficient old backup.
8) i also tried with following command to recover the database
RMAN> run {
SET UNTIL SEQUENCE 1033494 THREAD 1;
RECOVER DATABASE;
But it also not working ..

ora:01152 file 1 was not restored from a sufficient old backup.
ORA-01152: file string was not restored from a sufficiently old backup
Cause: An incomplete recovery session was started, but an insufficient number of logs were applied to make the database consistent. This file is still in the future of the last log applied. The most likely cause of this error is forgetting to restore the file from a backup before doing incomplete recovery.
Action: Either apply more logs until the database is consistent or restore the database file from an older backup and repeat recovery.
And how you taken database backup?
Regards,
Taj

Slow down Database after upgrading to 10.2.0.5

Hi
I am having performance problems after upgrading to 10.2.0.5
At the beginning I thought the problem was sga too smalle ( ini: 598M , now 1408M ) but even after recreating the database with the new value the problem remains.
I am sending reports so that someone could give me an idea.
Thanks in advance!
DETAILED ADDM REPORT FOR TASK 'TASK_240' WITH ID 240
Analysis Period: 22-JUN-2011 from 08:34:06 to 16:00:13
Database ID/Instance: 2462860799/1
Database/Instance Names: DXT/DXT
Host Name: thoracle
Database Version: 10.2.0.5.0
Snapshot Range: from 71 to 78
Database Time: 6726 seconds
Average Database Load: .3 active sessions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FINDING 1: 38% impact (2540 seconds)
SQL statements consuming significant database time were found.
RECOMMENDATION 1: SQL Tuning, 26% benefit (1763 seconds)
ACTION: Investigate the SQL statement with SQL_ID "30rku9qg2y30j" for
possible performance improvements.
RELEVANT OBJECT: SQL statement with SQL_ID 30rku9qg2y30j and
PLAN_HASH 2734400036
select a.owner, a.object_name, INSTR(a.object_type, :"SYS_B_00"),
:"SYS_B_01" from sys.all_objects a where a.object_type IN
(:"SYS_B_02",:"SYS_B_03") and a.status = :"SYS_B_04" and a.owner
like:"SYS_B_05"escape:"SYS_B_06" and a.object_name
like:"SYS_B_07"escape:"SYS_B_08" union all select c.owner,
c.synonym_name, INSTR(a.object_type, :"SYS_B_09"), :"SYS_B_10" from
sys.all_objects a, sys.all_synonyms c where c.table_owner = a.owner
and c.table_name = a.object_name and a.object_type IN
(:"SYS_B_11",:"SYS_B_12") and a.status = :"SYS_B_13" and c.owner
like:"SYS_B_14"escape:"SYS_B_15" and c.synonym_name
like:"SYS_B_16"escape:"SYS_B_17" union all select distinct b.owner,
CONCAT(b.package_name, :"SYS_B_18" || b.object_name),
min(b.position), max(b.overload) from sys.all_arguments b where
b.package_name IS NOT NULL and b.owner
like:"SYS_B_19"escape:"SYS_B_20" and b.package_name
like:"SYS_B_21"escape:"SYS_B_22" group by b.owner,
CONCAT(b.package_name, :"SYS_B_23" || b.object_name) union all select
distinct c.owner, CONCAT(c.synonym_name, :"SYS_B_24" ||
b.object_name), min(b.position), max(b.overload) from
sys.all_arguments b, sys.all_synonyms c where c.table_owner = b.owner
and c.table_name = b.package_name and b.package_name IS NOT NULL and
c.owner like:"SYS_B_25"escape:"SYS_B_26" and c.synonym_name
like:"SYS_B_27"escape:"SYS_B_28" group by c.owner,
CONCAT(c.synonym_name, :"SYS_B_29" || b.object_name) union all select
distinct c.owner, c.synonym_name, min(b.position), max(b.overload)
from sys.all_arguments b, sys.all_synonyms c where c.owner = b.owner
and c.table_owner=b.package_name and c.table_name=b.object_name and
c.owner like:"SYS_B_30"escape:"SYS_B_31" and c.synonym_name
like:"SYS_B_32"escape:"SYS_B_33" group by c.owner, c.synonym_name
RATIONALE: SQL statement with SQL_ID "30rku9qg2y30j" was executed 12270
times and had an average elapsed time of 0.036 seconds.
RATIONALE: Waiting for event "cursor: pin S wait on X" in wait class
"Concurrency" accounted for 7% of the database time spent in
processing the SQL statement with SQL_ID "30rku9qg2y30j".
RECOMMENDATION 2: SQL Tuning, 23% benefit (1550 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
"7yv1ba0c8y86t".
RELEVANT OBJECT: SQL statement with SQL_ID 7yv1ba0c8y86t and
PLAN_HASH 2684283631
Select WSTJ_.ROWID, WSTJ_.*, WMVD_.*
From THPR.STOJOU WSTJ_, THPR.SMVTD WMVD_ Where ((WMVD_.VCRTYP_0(+) =
WSTJ_.VCRTYP_0) AND (WMVD_.VCRNUM_0(+) = WSTJ_.VCRNUM_0) AND
(WMVD_.VCRLIN_0(+) = WSTJ_.VCRLIN_0))
And WMVD_.CCE2_0 = :1 And WSTJ_.IPTDAT_0 <= :2 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_0",:"SYS_B_1") <> :3 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_2",:"SYS_B_3") <> :4 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_4",:"SYS_B_5") <> :5 And
((WSTJ_.TRSFAM_0 = :6) Or (WSTJ_.TRSFAM_0 = :7))
Order by WSTJ_.STOFCY_0,WSTJ_.UPDCOD_0,WSTJ_.ITMREF_0,WSTJ_.IPTDAT_0
Desc,WSTJ_.MVTSEQ_0,WSTJ_.MVTIND_0
RATIONALE: SQL statement with SQL_ID "7yv1ba0c8y86t" was executed 47
times and had an average elapsed time of 32 seconds.
RECOMMENDATION 3: SQL Tuning, 14% benefit (926 seconds)
ACTION: Use bigger fetch arrays while fetching results from the SELECT
statement with SQL_ID "7yv1ba0c8y86t".
RELEVANT OBJECT: SQL statement with SQL_ID 7yv1ba0c8y86t and
PLAN_HASH 2684283631
Select WSTJ_.ROWID, WSTJ_.*, WMVD_.*
From THPR.STOJOU WSTJ_, THPR.SMVTD WMVD_ Where ((WMVD_.VCRTYP_0(+) =
WSTJ_.VCRTYP_0) AND (WMVD_.VCRNUM_0(+) = WSTJ_.VCRNUM_0) AND
(WMVD_.VCRLIN_0(+) = WSTJ_.VCRLIN_0))
And WMVD_.CCE2_0 = :1 And WSTJ_.IPTDAT_0 <= :2 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_0",:"SYS_B_1") <> :3 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_2",:"SYS_B_3") <> :4 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_4",:"SYS_B_5") <> :5 And
((WSTJ_.TRSFAM_0 = :6) Or (WSTJ_.TRSFAM_0 = :7))
Order by WSTJ_.STOFCY_0,WSTJ_.UPDCOD_0,WSTJ_.ITMREF_0,WSTJ_.IPTDAT_0
Desc,WSTJ_.MVTSEQ_0,WSTJ_.MVTIND_0
FINDING 2: 37% impact (2508 seconds)
Time spent on the CPU by the instance was responsible for a substantial part
of database time.
RECOMMENDATION 1: SQL Tuning, 26% benefit (1763 seconds)
ACTION: Investigate the SQL statement with SQL_ID "30rku9qg2y30j" for
possible performance improvements.
RELEVANT OBJECT: SQL statement with SQL_ID 30rku9qg2y30j and
PLAN_HASH 2734400036
select a.owner, a.object_name, INSTR(a.object_type, :"SYS_B_00"),
:"SYS_B_01" from sys.all_objects a where a.object_type IN
(:"SYS_B_02",:"SYS_B_03") and a.status = :"SYS_B_04" and a.owner
like:"SYS_B_05"escape:"SYS_B_06" and a.object_name
like:"SYS_B_07"escape:"SYS_B_08" union all select c.owner,
c.synonym_name, INSTR(a.object_type, :"SYS_B_09"), :"SYS_B_10" from
sys.all_objects a, sys.all_synonyms c where c.table_owner = a.owner
and c.table_name = a.object_name and a.object_type IN
(:"SYS_B_11",:"SYS_B_12") and a.status = :"SYS_B_13" and c.owner
like:"SYS_B_14"escape:"SYS_B_15" and c.synonym_name
like:"SYS_B_16"escape:"SYS_B_17" union all select distinct b.owner,
CONCAT(b.package_name, :"SYS_B_18" || b.object_name),
min(b.position), max(b.overload) from sys.all_arguments b where
b.package_name IS NOT NULL and b.owner
like:"SYS_B_19"escape:"SYS_B_20" and b.package_name
like:"SYS_B_21"escape:"SYS_B_22" group by b.owner,
CONCAT(b.package_name, :"SYS_B_23" || b.object_name) union all select
distinct c.owner, CONCAT(c.synonym_name, :"SYS_B_24" ||
b.object_name), min(b.position), max(b.overload) from
sys.all_arguments b, sys.all_synonyms c where c.table_owner = b.owner
and c.table_name = b.package_name and b.package_name IS NOT NULL and
c.owner like:"SYS_B_25"escape:"SYS_B_26" and c.synonym_name
like:"SYS_B_27"escape:"SYS_B_28" group by c.owner,
CONCAT(c.synonym_name, :"SYS_B_29" || b.object_name) union all select
distinct c.owner, c.synonym_name, min(b.position), max(b.overload)
from sys.all_arguments b, sys.all_synonyms c where c.owner = b.owner
and c.table_owner=b.package_name and c.table_name=b.object_name and
c.owner like:"SYS_B_30"escape:"SYS_B_31" and c.synonym_name
like:"SYS_B_32"escape:"SYS_B_33" group by c.owner, c.synonym_name
RATIONALE: SQL statement with SQL_ID "30rku9qg2y30j" was executed 12270
times and had an average elapsed time of 0.036 seconds.
RATIONALE: Waiting for event "cursor: pin S wait on X" in wait class
"Concurrency" accounted for 7% of the database time spent in
processing the SQL statement with SQL_ID "30rku9qg2y30j".
RATIONALE: Average CPU used per execution was 0.036 seconds.
RECOMMENDATION 2: SQL Tuning, 23% benefit (1550 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
"7yv1ba0c8y86t".
RELEVANT OBJECT: SQL statement with SQL_ID 7yv1ba0c8y86t and
PLAN_HASH 2684283631
Select WSTJ_.ROWID, WSTJ_.*, WMVD_.*
From THPR.STOJOU WSTJ_, THPR.SMVTD WMVD_ Where ((WMVD_.VCRTYP_0(+) =
WSTJ_.VCRTYP_0) AND (WMVD_.VCRNUM_0(+) = WSTJ_.VCRNUM_0) AND
(WMVD_.VCRLIN_0(+) = WSTJ_.VCRLIN_0))
And WMVD_.CCE2_0 = :1 And WSTJ_.IPTDAT_0 <= :2 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_0",:"SYS_B_1") <> :3 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_2",:"SYS_B_3") <> :4 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_4",:"SYS_B_5") <> :5 And
((WSTJ_.TRSFAM_0 = :6) Or (WSTJ_.TRSFAM_0 = :7))
Order by WSTJ_.STOFCY_0,WSTJ_.UPDCOD_0,WSTJ_.ITMREF_0,WSTJ_.IPTDAT_0
Desc,WSTJ_.MVTSEQ_0,WSTJ_.MVTIND_0
RATIONALE: SQL statement with SQL_ID "7yv1ba0c8y86t" was executed 47
times and had an average elapsed time of 32 seconds.
RATIONALE: Average CPU used per execution was 32 seconds.
RECOMMENDATION 3: SQL Tuning, 5.8% benefit (390 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
"cbtd2nt52qn1c".
RELEVANT OBJECT: SQL statement with SQL_ID cbtd2nt52qn1c and
PLAN_HASH 2897530229
Select DAE_.ROWID, DAE_.*, HAE_.*
From THPR.GACCENTRYD DAE_, THPR.GACCENTRY HAE_ Where ((HAE_.TYP_0(+)
= DAE_.TYP_0) AND (HAE_.NUM_0(+) = DAE_.NUM_0))
And HAE_.CPY_0 = :1 And HAE_.ACCDAT_0 >= :2 And HAE_.ACCDAT_0 <= :3
And DAE_.ACC_0 = :4 And HAE_.FCY_0 >= :5 And HAE_.FCY_0 <= :6
Order by DAE_.BPR_0,DAE_.CUR_0,DAE_.ACC_0
RATIONALE: SQL statement with SQL_ID "cbtd2nt52qn1c" was executed 12980
times and had an average elapsed time of 0.03 seconds.
RATIONALE: Average CPU used per execution was 0.029 seconds.
RECOMMENDATION 4: SQL Tuning, 2.1% benefit (138 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
"33t7fszkr29gy".
RELEVANT OBJECT: SQL statement with SQL_ID 33t7fszkr29gy and
PLAN_HASH 2684283631
Select WSTJ_.ROWID, WSTJ_.*, WMVD_.*
From THPR.STOJOU WSTJ_, THPR.SMVTD WMVD_ Where ((WMVD_.VCRTYP_0(+) =
WSTJ_.VCRTYP_0) AND (WMVD_.VCRNUM_0(+) = WSTJ_.VCRNUM_0) AND
(WMVD_.VCRLIN_0(+) = WSTJ_.VCRLIN_0))
And WMVD_.CCE2_0 = :1 And WSTJ_.IPTDAT_0 <= :2 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_0",:"SYS_B_1") <> :3 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_2",:"SYS_B_3") <> :4 And
Substr(WMVD_.ITMDES1_0,:"SYS_B_4",:"SYS_B_5") <> :5 And
(((WSTJ_.TRSFAM_0 = :6) Or (WSTJ_.TRSFAM_0 = :7)))
Order by WSTJ_.STOFCY_0,WSTJ_.UPDCOD_0,WSTJ_.ITMREF_0,WSTJ_.IPTDAT_0
Desc,WSTJ_.MVTSEQ_0,WSTJ_.MVTIND_0
RATIONALE: SQL statement with SQL_ID "33t7fszkr29gy" was executed 1
times and had an average elapsed time of 136 seconds.
RATIONALE: Average CPU used per execution was 138 seconds.
FINDING 3: 15% impact (1008 seconds)
SQL statements with the same text were not shared because of cursor
environment mismatch. This resulted in additional hard parses which were
consuming significant database time.
RECOMMENDATION 1: Application Analysis, 15% benefit (1008 seconds)
ACTION: Look for top reason for cursor environment mismatch in
V$SQL_SHARED_CURSOR.
ADDITIONAL INFORMATION:
Common causes of environment mismatch are session NLS settings, SQL
trace settings and optimizer parameters.
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Hard parsing of SQL statements was consuming significant
database time. (20% impact [1336 seconds])
SYMPTOM: Contention for latches related to the shared pool was
consuming significant database time. (2% impact [135
seconds])
INFO: Waits for "cursor: pin S wait on X" amounted to 1% of
database time.
SYMPTOM: Wait class "Concurrency" was consuming significant
database time. (2.3% impact [154 seconds])
FINDING 4: 8.5% impact (570 seconds)
Wait class "User I/O" was consuming significant database time.
NO RECOMMENDATIONS AVAILABLE
ADDITIONAL INFORMATION:
Waits for I/O to temporary tablespaces were not consuming significant
database time.
The throughput of the I/O subsystem was not significantly lower than
expected.
FINDING 5: 5.3% impact (355 seconds)
The SGA was inadequately sized, causing additional I/O or hard parses.
RECOMMENDATION 1: DB Configuration, 3.2% benefit (215 seconds)
ACTION: Increase the size of the SGA by setting the parameter
"sga_target" to 1740 M.
ADDITIONAL INFORMATION:
The value of parameter "sga_target" was "1392 M" during the analysis
period.
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Hard parsing of SQL statements was consuming significant
database time. (20% impact [1336 seconds])
SYMPTOM: Contention for latches related to the shared pool was
consuming significant database time. (2% impact [135
seconds])
INFO: Waits for "cursor: pin S wait on X" amounted to 1% of
database time.
SYMPTOM: Wait class "Concurrency" was consuming significant
database time. (2.3% impact [154 seconds])
SYMPTOM: Wait class "User I/O" was consuming significant database time.
(8.5% impact [570 seconds])
INFO: Waits for I/O to temporary tablespaces were not consuming
significant database time.
The throughput of the I/O subsystem was not significantly lower
than expected.
FINDING 6: 4.2% impact (281 seconds)
Cursors were getting invalidated due to DDL operations. This resulted in
additional hard parses which were consuming significant database time.
RECOMMENDATION 1: Application Analysis, 4.2% benefit (281 seconds)
ACTION: Investigate appropriateness of DDL operations.
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Hard parsing of SQL statements was consuming significant
database time. (20% impact [1336 seconds])
SYMPTOM: Contention for latches related to the shared pool was
consuming significant database time. (2% impact [135
seconds])
INFO: Waits for "cursor: pin S wait on X" amounted to 1% of
database time.
SYMPTOM: Wait class "Concurrency" was consuming significant
database time. (2.3% impact [154 seconds])
FINDING 7: 4% impact (266 seconds)
Waits on event "log file sync" while performing COMMIT and ROLLBACK operations
were consuming significant database time.
RECOMMENDATION 1: Host Configuration, 4% benefit (266 seconds)
ACTION: Investigate the possibility of improving the performance of I/O
to the online redo log files.
RATIONALE: The average size of writes to the online redo log files was
26 K and the average time per write was 2 milliseconds.
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Wait class "Commit" was consuming significant database time.
(4% impact [266 seconds])
FINDING 8: 2.9% impact (192 seconds)
Soft parsing of SQL statements was consuming significant database time.
RECOMMENDATION 1: Application Analysis, 2.9% benefit (192 seconds)
ACTION: Investigate application logic to keep open the frequently used
cursors. Note that cursors are closed by both cursor close calls and
session disconnects.
RECOMMENDATION 2: DB Configuration, 2.9% benefit (192 seconds)
ACTION: Consider increasing the maximum number of open cursors a session
can have by increasing the value of parameter "open_cursors".
ACTION: Consider increasing the session cursor cache size by increasing
the value of parameter "session_cached_cursors".
RATIONALE: The value of parameter "open_cursors" was "800" during the
analysis period.
RATIONALE: The value of parameter "session_cached_cursors" was "20"
during the analysis period.
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Contention for latches related to the shared pool was consuming
significant database time. (2% impact [135 seconds])
INFO: Waits for "cursor: pin S wait on X" amounted to 1% of database
time.
SYMPTOM: Wait class "Concurrency" was consuming significant database
time. (2.3% impact [154 seconds])
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ADDITIONAL INFORMATION
Wait class "Application" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
Wait class "Network" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
The database's maintenance windows were active during 100% of the analysis
period.
The analysis of I/O performance is based on the default assumption that the
average read time for one database block is 10000 micro-seconds.
An explanation of the terminology used in this report is available when you
run the report with the 'ALL' level of detail.

user12023161 wrote:
I have upgraded 10.2.0.3.0 to 10.2.0.5.0 and facing same issue. The database is slow in general after upgrade compared to 10.2.0.3.0.Try setting OPTIMIZER_FEATURE_ENABLE parameter to 10.2.0.3.
Refer following link:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams142.htm

Aperture Library/Database hacks

After one week playing around with aperture, i want to share my current insights with 'customizing' (my) aperture's way of dealing with my picture files.
Warning:
The following thoughts and arrangements are working for me, they're
undoubtly NOT supported by apple and the programmers of the aperture
application!
Reading a lot of articles in the forum when aperture hit the masses, i've been disappointed about how aperture will fit with me.
Over the years my growing picture collection moved over from one computer to the other, deploying more storage, and will continue to do so in the future. So the technical equipment has to be independent from the treasure's of my data, to follow state of the art hard- and software development.
For me, aperture approved to be of such a kind.
Despite aperture stores away all my digital masters into it's own Library, thus duplicating data during imports, it just brings in some kind of more detailed
directory hierarchies to my way of organizing my picture library. How does it do?
How do i store my Library?
Sorry to be that longish, but to explain my concepts i have to.
Modern operating systems distinguish private/personal and public/common data for their file storage locations. Hopefully they follow the 'FHS' (Filesystem-Hierarchical-Standard) brought up by linux, to name the diverse locations for classified data.
I do run mixed os'es within my networks, as no computer should be isolated from a networked environment anymore. But to be honest it's more a single-user situation in reality, then the multi-user aspects i always keep in mind when designing my infrastructure environment for a network.
My picture library/online-archive is classified 'common' data, so it stores outside my home-directory, and every user allowed to, has access to it. I do not support locales within my filenaming-conventions, users and me are german-spoken, so the 'common' data for my systems is always called
'/Bibliothek'.
Furthermore we're dealing with pictures (Bild), movies (Film), music (Musik) and documents (Dokumente) in all common used operting systems (os x, windows), storing private data to the home-directory within appropiate directories and public/common data to the equivalent directories at a common storage.
/Bibliothek
/Bibliothek/Bildarchiv
/Bibliothek/Filmarchiv
/Bibliothek/Musikarchiv
BTW, i customized windows to reflect this filetree within explorer windows, so users click to 'Eigene Bilder' (my pictures) and 'Bildarchiv' (common pictures) there, to change between directories, making it very convenient to work with.
Especially the 'common' picture files are strongly organized by date, which is reflected at the directory-structure, for example:
'/Bibliothek/Bildarchiv/2004/2004-04-17, make a good description/'
'/Bibliothek/Bildarchiv/2005/2005-12-00, a bunch for the whole period/'
A descriptive directory name is highly portable between operating systems, applications and last but not least, users!
For now, aperture seems to be pretty much a single-user solution.
But it's library can be 'distributed' to accomodate my needs.
I started to import my data by drag'n'drop, which works best for me. I didn't like the import assistent, which seemed to result in a different structure of my data in aperture's 'all projects' list. By creating a folder in aperture for the year, then drag'n'drop the multi-selected directories from the finder, i got within aperture:
All Projects + * (<-Aperture)
<div class="jive-quote">Library (smart-albums, collapsed)
2005 (folder)
2005-11-00 (folder, nested)
2005-11-17, sample bla (project, from directory)
Images from 2005-11-17, sample bla (album, inherited)
2005-12-08, take a better name (project)
Images from 2005-12-08, take a better name
Using aperture's preferences to switch between libraries i did import to different aperture libraries for the years, resulting in a bunch of directories, each holding an 'Aperture Library.aplibrary' paket there.
/Bibliothek/Bildarchiv/2004/2004.aplibrary
/Bibliothek/Bildarchiv/2005/2005.aplibrary
Yes, the pakets can be renamed, to better reflect whats in there. Aperture has to be restarted to change from one library to another!
The total amount of imported data, yet: 130 GB, ~33164 pics.
I am working with a 15" powerbook, 1,5gb ram, 80 gb hdd on the road and a 200gb external drive at home/office.
to make me feel comfortable with aperture, i switched to (terminal hacking!):
~me/Pictures/Aperture Library.aplibrary/
~me/Pictures/Aperture Library.aplibrary/2004/ ->
/Bibliothek/Bildarchiv/2004/2004.aplibrary
~me/Pictures/Aperture Library.aplibrary/2005/ ->
/Bibliothek/Bildarchiv/2005/2005.aplibrary
~me/Pictures/Aperture Library.aplibrary/Texturen/ ->
/Bibliothek/Bildarchiv/Texturen/Texturen.aplibrary
~me/Pictures/Aperture Library.aplibrary/...
/Bibliothek/Bildarchiv/2004/2004.aplibrary
/Bibliothek/Bildarchiv/2005/2005.aplibrary
/Bibliothek/Bildarchiv/Texturen/Texturen.aplibrary ->
/Volumes/HD39.1/Bibliothek/Bildarchiv/Texturen/Texturen Library.aplibrary
Linking folders to where i believe they are right placed in my systems.
Now aperture's settings don't have to be changed each time to switch between libraries. Not connecting the external hdd gives me grayedout
folders within aperture, for data stored on the external drive. Having a folder located on my inetrnal hdd and 'linked' to aperture:
~me/Pictures/Aperture Library.aplibrary/local ->
/Bibliothek/Bildarchiv/working.local.aplibrary
i can work with aperture normally, even if the external drive is not available.
the grayedout folders/subfolders/projects are browsable, but all thumbnails are just gray rectangles with its 'version name' underneath. same with smart-albums. available pics have colored thumbnails, unavailable pics are gray, naturally.
And aperture's database? well, i am very happy with it, really. Compared to my pre-aperture structure all the above mentioned tweaking gave me:
~me/Pictures/Aperture Library.aplibrary/Aperture.aplib/Library.apdb
This file is actually the sqlite3 database file. it's size is 111 MB now.
~me/Pictures/Aperture Library.aplibrary/Local ->
/Bibliothek/Bildarchiv/Working.local.aplibrary
I can store pictures there into folders and projects when i am on the road, filling up my local harddisk. Inspecting the paket shows up how aperture differenciated my pre-aperture filestructure:
/Bibliothek/Bildarchiv/Working.local.aplibrary/2005-12-08, take a better name.approject/2005-12-08 @ 01/49/06 PM - 1.apimportgroup/DSC0168/dsc0168.nef
All nicely packed into a single unit from the finder, easily browsable from aperture, and searchable by sql queries. Every Master enclosed in its own folder box, hm. Every import of files seperated to one folder, which makes clearly apparent that we will import redundant(duplicate) files for ever.
Adding two/three levels to my previous filestructure, strange namings all inclusive. As i sort my files with aperture into projects, the files accordingly move around at the filesystem-level. I'll let them go. They are there if i need access to them in case of failure.
T H E G L I T C H E S
within my setup the most current sql database is stored at:
~me/Pictures/Aperture Library.aplibrary/Aperture.aplib/Library.apdb
importing the way i did results in a sqlite3-database file for each library i switched to before linking them together. Right after linking one of those aplibrary pakets as a new folder, aperture will rebuild the current database at startup, which can indepently be invoked with 'option command aperture' anytime the program is started.
Changes to the metadata of a picture are written to the current database aperture is running on, but can be transfered to any other database file
when rebuilding the library at startup (which can be a time-consuming thing!)
Even if the external hd is reconnected before startup, some thumbnails are not properly generated all the time. At the current state i don't have any glue what's the cause for this. All Versions are properly accessable anyway.
Once again,
DO THIS AT YOUR OWN RISK,
if you try some of the suggestions i've made. Better you know how to handle a terminal before you even think about what i told here. Don't bother me, if something does not work for you - it works for me.
I can do this because it's my data, i am the only one affected by failure and i still do have my data on my windows system as a backup, for now.
Do the same before you trash your treasures.
Why i did made this post? Aperture really lacks support for team-working now. I cannot see how aperture can be really employed to its potential for an environment with more than a single user?. The sqlite3 database is said to handle concurrent users, i read on its homepage. So i still hope, there will be a group-worked aperture someday.

my reports, just for the logs.
drwxr-xr-x 2 fo03c fo03c 68 Dec 19 20:15 ArchiveInfo
-rw-r--r-- 1 fo03c fo03c 362 Dec 19 20:17 DataModelVersion.plist
-rw-r--r-- 1 fo03c fo03c 173107200 Dec 20 00:26 Library.apdb
comparing the timestamps, the time needed to recreate 'my' library, is:
4h 11 min.
The sql database contains 972 projects with 57952 picture items, as the startup overlay tells me. not that bad, i think. depends on the situation, and how much zen you learned, if you can wait for the 'recreate'.
but i didn't stop to mature aperture!
i switched to one of my 'old' libraries (choosing from preferences panel) and set some new
a) ratings
b) keywords
c) deleted a master from that 'old' library.
after changing back to the 'linked' aperture database file (within my home-directory, as described previously), and restart aperture -
yes, it crashed! oops.
yet another try - crash. i realized, i deleted the first pic from the 'current view' aperture tries to load after relaunch. ?! =:-(
if the database is corrupted again, i would have to reinvest ~4 hours to recreate the database? but how about the preferences?
apple this is a bug! when i made the preferences file
~me/Library/Preferences/com.apple.Aperture.plist
UNAVAILABLE (delete or rename as you like), aperture starts with the import assistent, as at its first time.
Since then i can start aperture and navigate to the project i deleted the file from (very unpolitly). The corresponding thumbnail shows up with a new 'icon' to lower right corner of the thumbnail. It clearly means: this file is UNAVAILABLE.
YES =:-) i deleted it!
the rating and keywording on the 'old' database is gone -
thus making the precedence of the database against the sidecars obvious, doensn't it?
selecting the 'orphaned' thumbnail, now leaves aperture with the message 'loading', but it does not crash. Changes in ratings or keywording to the current library (the 'recreated' new one) on different files are persitent across restarts of aperture. btw, aperture restarts with the focus on the orphaned first thumbnail, now marked with the icon 'i am NOT available', but it does not crash anymore, when starting.
my conclusion:
someone in the forums pointed towards the difficulties maintaining a database of pictures and the separation of their storage, as users will delete or move files seperated from that database, breaking everything.
NO, aperture does widely tolerate such doing.
But why should we do so? =:-)f
For me: its fun, i will not complain about failure, when i do mature an application like this.

ReCreate my Database

Similar Messages

Maybe you are looking for