Databases Reference
In-Depth Information
create restore point BEFORE REL 2 3 0 1;
You can list all restore points by running the command:
SELECT name FROM v$restore point;
After running the patch script and fixing all issues, you can easily reset the database state by issuing
the following commands as the user
SYS
:
shutdown immediate;
startup mount;
flashback database to restore point BEFORE REL 2 3 0 1;
alter database open resetlogs;
Repeat this procedure with running the scripts, fixing the scripts, and resetting the database until
the scripts install without any problem .
The last step in this procedure is to commit the modified files into Subversion, so that the changes
are visible in the next patch.
Update the Documentation
At this point you can update the documentation. Up until now all documentation regarding the specific
release only described the differences (added, removed, or changed functionality) with respect to the
previous release. In this step you will have to incorporate the delta documentation into the overall
documentation. This is the only way to keep the overall system documentation current with the
complete description of use cases, function points, data model, system design, and the like.
The release history will be recorded in the operation guide. There, you enter the exact version and
the date the version was installed in the production system. We have included an example (see Table 9-
5); already you can see that we have started on 11.11.2010 to deploy a second application (Application Y)
in production that is directly dependant on version 3.2.0 of Application X.
Table 9-5.
Release Version Overview
Application X
Application Y
Installed in Production
3.2.0
1.0.0
11.11.2010
3.1.0
28.06.2010
3.0.0
19.04.2010
2.3.1
19.01.2010
2.3.0
13.11.2009
2.2.0
28.10.2009
2.1.0
31.08.2009
2.0.0
12.06.2009
