I have just completed a Webinar at BrainSurface Virtathon.
I have uploaded a copy of the presentation 'Oracle Database "Performance" - A Diagnostics Approach' at my "Oracle Diagnostics Presentations" site.
As I demonstrated in my previous blog post "ENABLE ROW MOVEMENT" the ALTER TABLE ... ENABLE ROW MOVEMENT is not just for supporting the ALTER TABLE ... SHRINK SPACE.
Furthermore, unlike ALTER TABLE ... SHRINK SPACE which requires that the Table be created in a Tablespace with Segment Space Management AUTO ("ASSM"), ENABLE ROW MOVEMENT can be done for a table in a Segment Space Management MANUAL ("MSSM") Tablespace as well.
SQL> create tablespace MSSM
Since the ALTER TABLE SHRINK command appeared and "ENABLE ROW MOVEMENT" has been presented as a requirement, some DBAs have been confused about what it means to enable row movement.
This does *NOT* cause Oracle to automatically move a row. However, a row may be moved as a result of action by the DBA (e.g. ALTER TABLE SHRINK) or a User / Application. The latter is the case where a row in a Partitioned Table has to move from one Partition to another because the Partition Key itself in that row has been updated.
Given this extract from an AWR :
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.93 In-memory Sort %: 100.00
Library Hit %: 94.76 Soft Parse %: 96.21
Execute to Parse %: 30.63 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 79.13 % Non-Parse CPU: 93.52
Should I be worried about the Parse ratios ?
Occasionally, we come across questions about multiple channels and parallelism in RMAN.
Although RMAN distributes the datafiles across the channels, it doesn't necessarily mean that each channel has the same I/O requirements and needs the same amount of time. One channel may be reading more data and writing a larger backup than another.
For example, in this database with 16 datafiles where data is not equally distributed across all the datafiles :
SQL> select file_id, sum(blocks) from dba_extents group by file_id order by 1;
A few weeks ago, there was a question about disabling TRUNCATEs. That can be easily done via a Trigger.
SQL> -- create a trigger that raises an error on truncates
SQL> create or replace trigger prevent_truncates
2 before truncate on schema
4 raise_application_error(-20001,'TRUNCATE not permitted');
Here's a video by Stephane Faroult (RoughSea) : "Are you ready 2.0 ?"