Can an active session in oracle be dead

The Active Session Pool allows a limit to be place on the number of sessions that can be active on your instance. It is a part of the Resource Manager. The number possible is defined according to your current resource plan. The default plan allows an unlimited number of sessions. It is activated if resource management is performed in the instance. To find out if this is so then check the resource_manager_plan parameter:

show parameter resource_manager_plan

If there is a value then it is activated. You may see something like DEFAULT_PLAN as the VALUE. You can then query DBA_RSRC_PLAN_DIRECTIVES for the number of active sessions possible:

select GROUP_OR_SUBPLAN, ACTIVE_SESS_POOL_P1
  from DBA_RSRC_PLAN_DIRECTIVES
 where PLAN = 'DEFAULT_PLAN';

You'll get a few rows back relating to the number of groups/subplans that are part of this plan. NULL will indicate unlimited. I prefer using Enterprise Manager to query and amend this. To find it in EM go to the Server tab then under the Resource Manager heading is Plans.

More information on the Resource Manager can be found here.

1. Close, I think you should be concerned with the redo itself rather than the log switches it is causing.
2. I think this is because fast_start_mttr_target is set to zero, but again this should not be the issue to focus on.
3. Here is the heart of the matter:

Since you can't change the source database to have a materialized view log, every MV refresh has to delete all the records and re-insert them all, which creates your excessive redo. There are many different approaches you could take to this issue. Here are some.

• Simply increase the redo log size. This will decrease the impact of frequent switches, but the redo will still be generated.
• Roll your own Materialized View. This is more work, but would probably generate significantly less redo.
  
  • Your refresh could Truncate the table and do an insert with the Append hint if you can tolerate the absence of data during the refresh.
  • Drop the table and do a CTAS from the source with the append hint is another option that sacrifices availability for speed and reduced redo.
  • If you need the data to be available you could selectively update and insert data based on what actually changed. This would introduce a bit more load on the source database, but would probably decrease your redo significantly.
  • Depending on your data needs you might get away with only handling inserts above the last known sequence number, and/or updates when only certain significant columns have changes. The more custom the solution the less redo, but also the more work to maintain.
• A more drastic approach would be to recover the tablespace involved to your second database periodically, but since you are using XE, that probably isn't an option.