Re: Y2K Testing

Ron & Allan:

"What happens if I reset my shutdown my database, set the system date to the year 2000, run my tests, shutdown the database, reset the date to the current date, and re-start the database? Do bad things happen?"

My opinion is that you're setting yourself up for problems. I'd like to know, as does Ron, if this is your production database you're testing against or have you duplicated it and placed it a separate environment. If your testing with your current production database, you could have serious data corruption and integrity issues. You may experience file time-stamp issues as well.

To test your Oracle database in future targeted dates, you must create a safe, independent environment (an environment physically disconnected from production systems or on a dedicated box).

May I offer a suggestion and potential solution?

Utilize a date & time simulator such as Time Machine. Time Machine (TM) is a date and time simulation tool developed specifically at the request of the manufacturers to expedite Y2K compliance testing. It allows for concurrent testing of up to 200 virtual clocks on the same box without effecting the system clock, thus causing havoc. Moreover, it has a logging feature which allows you to track testing progress to show due diligence is being served. If you have time-sensitive apps on your system, you place them on an exclusion list to prevent expiration. It is a very well written utility created by a former HP software architect for this Y2K testing scenario.

You probably saying, "Hey, what about Oracle issues?!"

It's coming...

Multiple Oracle applications can be tested with different virtual times concurrently on the same system. Test environment setup is streamlined, since no costly reload is necessary after each change of TM’s virtual time. Users can even test their Oracle applications (with test databases) right on their production systems!

Since non-Y2K ready applications may malfunction or damage production data, it is of utmost importance to NOT perform Y2K assessment and testing directly against the production data. It is recommended that users copy their production environment into a test environment, then work on the test data only.

First, let’s go over some basics. TM configures virtual clocks by user ids. Each copy of an Oracle binary (program) has its own user id. All Oracle database instances associated with the same Oracle binary share that same user id. Finally, an Oracle user has their own user id and it is typically different than the user id of the Oracle binary.

An Oracle application may ask the operating system for date & time information, or it may ask Oracle for date & time information (ex. SYSDATE). Without knowing exactly how the applications are written, it is safest to synchronize both the Oracle user and Oracle server (binary) to see the exact same virtual time. This way, the application will always get a consistent time no matter how it asks for date & time.

"So how could I set up an Oracle Y2K test environment with this thing?" you're asking yourself...

A typical procedure to setup a virtual time with an Oracle testing cycle involves:

1. Making sure that no Oracle database instances are active for the target Oracle binary
2. Using TM to set the exact same virtual time to the user ids for both the tester and the Oracle binary
3. Starting up the Oracle database instances
4. Y2K testing
5. Shutting down the Oracle database instances

Step A is necessary, since we don’t want to "switch time" when a database is open/active!

Step D can involve testing of multiple Oracle applications with the same virtual time.

If users plan to perform Y2K testing on their production systems, then users must install another copy of the Oracle binary for the test environment. This way, the production data will always see the current time via the original Oracle binary copy.

If users plan to perform Y2K testing with multiple Oracle application with different virtual times concurrently on the same system, then users must install a copy of Oracle binary (with different user id) for each concurrent test environment.

It is recommended that new users are created for each tester in the test environment. Try not to share the same user id with multiple testers to avoid confusion (especially if they may travel to different virtual time concurrently).

I know. I know. You asking yourself, "What about changing to a different virtual time, smartguy?"

Once an Oracle database instance shuts down, no recovery is performed the next time the database starts up. Therefore, users are free to launch the test environment (Oracle binary and tester’ user ids) to a different virtual time as long as all database instances associate with the Oracle binary shut down before the time change.

Some users are wondering if they need to reload the database once the virtual time goes backward. The answer is NO. This condition may occur in the "real world". If a database in the east coast shuts down, then ftp transfers to the west coast, it would work just fine when it starts up. The key is to first shut down the database.

And refreshing the database contents?

Some test strategies, such as baseline testing, require that the database contents to be exactly the same at the beginning of each test cycle. One obvious choice is to restore the whole database from tape. A faster way is to use the System Commit Number (SCN) recovery method. Users can note the SCN at the beginning of a test cycle and recover with that SCN to rollback all modifications at end of a test cycle.

Of course, if the test is read-only, then such a procedure is not necessary, since the database contents remain the same.

In using Time Machine with Oracle, there are two areas to consider: how many virtual clocks you would like to test concurrently and if the database contents need to be refreshed at the beginning of each test cycle.

When testing TM with Oracle, you will need to install one binary copy of Oracle for every virtual clock you plan on testing concurrently. Each binary copy and its disjoint set of users will need to synchronize to the same virtual time. As long as we shut down all databases associated with a binary copy before we launch to a different virtual time, users are free to travel forward or backward in time.

If the test cycle calls for refreshing the database, then recovering with the SCN is a more desirable alternative to restoring the databases from tape.

That was a mouthful but I think it offered a potential solution to you problem you posted. Drop me an email if you have questions or even a data sheet on Time Machine. OK? I hope the rest of you're testing goes smooth and I hope I can help you out.

Harrison Caldwell
hcaldwell_at_solution-soft.com

In article <36E58FB6.EE6D873_at_us.oracle.com>,   Ron Leedy <rleedy_at_us.oracle.com> wrote:
> That depends on:
>
> a) what is in your database?
> b) what are you doing in your testing?
> c) what do you consider bad things?
> d) is this your production database?
>
> The biggest problem would be if you have event driven transactions in
> your database or part of your testing. It could trigger those off or
> create unneccessary transactions to kick off later. It will not effect
> any of the system catalogues if that is what is "bad".
>
> Allan Kelly wrote:
> >
> > What happens if I reset my shutdown my database, set the system date to the
> > year 2000, run my tests, shutdown the database, reset the date to the
> > current date, and re-start the database? Do bad things happen?
>
> --
> ------------------------------------------------------------------
> Ronald Leedy rleedy_at_us.oracle.com
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> Live as is if you were to die tomorrow.
> Live as if you would live forever.
> ------------------------------------------------------------------
>

-----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own Received on Sat Mar 13 1999 - 00:00:00 CET