|
Feb 25, 2008 - 03:11 AM
|
||||||
![]() |
||||||
Main Menu
ORA- SearchDoc Search
|
We received an urgent priority ticket to resolve a performance issue for a sql statement which was running for 4-5 hours and throwing snapshot too old error. The query was based on finding out the duplicate records and involved joins. There were 3 tables involved in join. The 2 tables were 500 MB in size and around 500-600k records. The 3rd table was 40GB with 20-25 millions of records. The select statement was fetching records from 3rd table and joining with other 2 tables. To expedite the report processing I created an index on 4 columns, the columns of big table. A composite index. 1. Index with nologging and parallel clause. The 1st attempt failed because of temporary tablespace errors. In the 2nd attempt, we
After the index creation I used dbms_stats.gather_table_stats with cascade option and degree 5. It was 6 processor machine so we followed n-1 rule. We ran the sql statement and the query finished in 1 minute 40 seconds. The concept is Index Fast Full Scan.
I want
to share my experience with alter table move tablespace. I was handling
a project to migrate data mart database tables from dictionary managed
tablespace to locally managed tablespace. The m_gnap_records table size was around 40GB and it had 210 columns. When I started this assignment, the existing plan was based on the following approach: alter table m_gnap_records move tablespace nologging; a.
alter table m_gnap_records nologging; Time Taken: 1 hour 55 minutes.
I tested the following also to verify the approach: alter
table m_gnap_records logging; Time taken : 4 hours 48 minutes
I was working on a large import process. My application user provided the export file of size around 10GB. I started the import process and it finished in approximately 2 hours ( no indexes and constraints). imp / buffer=102400000 file=/tmp/table.p fromuser=NTUSER touser=NTUSER indexes=N constraints=n statistics=None grants=N recordlength=65535 ignore=Y commit=Y ANALYZE=N rows=y feedback=500000 After the above operation I had to run an update for 20 million records.The update operation generated around 10 GB of redo. All the tables were in no logging mode. I spent couple of hours to dig out the reason of large number of archive logs and overall update performance. I decided to use logminer to read the archive logs to gather the details on the objects causing large redo.I copied the production archive log in the lab server and did the following: The prod db was Nprod and lab db was NLAB. Starting Logminer ALTER DATABASE FORCE LOGGING; BEGIN The sql_redo and sql_undo had reference Object#.
select object_id,object_name,owner from dba_objects where object_id in(57190,57188,64455,6379);
|
|
||||||||||||||||||||||||||||||||||||||||||
| Your Choice.......................Your Info |