ORA-20223: Invalid input. Database has not been INITIALIZED for REPLAY

The Problem

As part of the set-up work you have to do before replaying a  captured workload into the DB using Real Application Testing, you have to run  various commands. This is one of them, but I was receiving errors:

3     synchronization           => ‘SCN’,
4     connect_time_scale        => 100,
5     think_time_scale          => 100,
6     think_time_auto_correct   => TRUE,
7     scale_up_multiplier       => 1,
8     capture_sts               => TRUE,
9     sts_cap_interval          => 1800);
10  END;
11  /
ERROR at line 1:
ORA-20223: Invalid input. Database has not been INITIALIZED  for REPLAY. Issue
ORA-06512: at “SYS.DBMS_WORKLOAD_REPLAY”, line  2757
ORA-06512: at line 2
The Solution

The error is quite self-explanatory; you need to issue the INITIALIZE_REPLAY  procedure from within the DBMS_WORKLOAD_REPLAY package before you can run the  PREPARE_REPLAY procedure.

You may have moved past this stage and are trying to connect the replay clients to the DB, but are experiencing ORA-15554: cannot start workload replay client or perhaps you have not made it as far as this and are trying to work out how to enable Real Application Testing (RAT) in your database.

Like it, share it...

Category: RAT

Related Posts

Comments (2)

Trackback URL | Comments RSS Feed

  1. Teguh says:

    a column data store, think of it this way.normally we store rows, on a block we would have(c1, c2, c3), (c1, c2, c3) …..With clmounar storage – we store all of the c1 values AND THEN the c2 values AND THEN the c3 values and then have a row lookup that lets us reference these column values (like pointers)if that were all, it would not compress anything – but….when we build the C1 array of data – we deduplicate it (pretend we are loading an audit trail, lots of IP addresses would be repeated in C1).and after de-dupping it, we compress it (lots of repetition again in IP addresses the leading edges might all be the same in fact). so, we store hundreds of thousands of IP addresses in a few bytes.And then we do that to column c2, and c3. Then we point to this data.That allows us to spend (a lot) of cpu time during the load to rearrange the data, de-dup it, compress it and store it – so at retrieval time we might have 1/50th of the data to scan through – decompressing is FAST, compressing is very slow (that is why we’ll offload lots of work to exadata)

Leave a Reply

Your email address will not be published. Required fields are marked *