Just another Adobe Blogs site

The Upgrade Readiness tool is a part of the ERT(Enterprise Readiness Tool) which analyzes the customer’s legacy environment from ‘upgrade to ADEP Document Services’ perspective. It checks the environment of the customer and gives recommendations to the user about the changes he needs to make in order to be able to upgrade his existing LiveCycle Server to ADEP Document Services 10.0. The Upgrade Readiness tool needs a connection to an existing running LiveCycle Server in order to be able to analyze various aspects of the customer’s environment.

Upgrade Readiness tool checks for the following

Environment-

Operating system – Checks if the current operating system supports Document Server.

Application Server version- Checks if the current application server version hosting LiveCycle is fit for hosting Document Services.

RAM- Checks the amount of RAM

JDK- Checks the version of the JDK needed

Database driver and database version

The upgrade readiness tool also checks for the following runtime aspects of the LiveCycle Server

LiveCycle 7 compatibility layer version.

Presence of QPAC based processes

Presence of BAM (no longer supported in ADEP Document Services 10.0)

Presence of PDFG and PDFG3D.

This tool checks for the presence of LiveCycle processes which could be upgraded from process model to application model and lists them in the validation report. Figure a and figure b show the Start screen of the upgrade Readiness tool and the subsequent report generated after the execution respectively.

Here is the screenshot of a figure showing the Upgrade Readiness tool in the ERT

Upgrade readiness tool

Following figure illustrates the summary of validations in a report generated by the ERT

Summary of validations

The summary of the validations is followed by a detailed section, which gives recommendations to resolve the failed validations. The details section is illustrated in the following figure

Details of validations

Please keep in mind that the recommendations given by Adobe ERT are for upgrades on the ‘same machine’. If a user wants to upgrade his hardware/Operating system as well, then Out of place upgrades are also possible. In such scenarios the user might have other options which are not recommended by the ERT due to older hardware of the current system (like choices of other versions of databases, application servers etc)

For more information on the Enterprise Readiness tool visit the following link

For more information on upgrading the document services please refer to the Upgrading section of the ADEP Documentation

The administrator can obtain a complete ‘point in time’ backup of a CRX repository using curl commands or by issuing the commands through the GUI. The benefit of curl commands is that they are easier to automate.

Here is the command (meant to be executed from Windows shell after setting up curl on the system.

The workbench has a feature to record the execution of a particular process and the workbench user can later view the step by step execution of the process. This feature is immensely helpful in observing the flow of control of a process for debugging purpose. One can also stop and view the values of variables at a point in time of execution. Following figures illustrate the working of this feature.

The maintenance mode shuts down the job scheduler service so that the pending jobs don’t get triggered when the administrator intends to carry out maintenance activities ( e.g. restoring from a backup, upgrading software, applying a patch etc). This feature is of immense help when the administrators don’t want the Document Server to process pending jobs.

It is particularly helpful in scenarios when the Document Server is not fully functional and few services are not working yet (e.g. during upgrade execution some services are not functional until their respective plug-ins have executed). In such a scenario if the pending jobs would start getting triggered then they would stall because of the ‘lack’ or ’not working’ of services on which they are dependent on.

There are couple of ways to put Document services into maintenance mode

This method gives us the ability to start the document server in maintenance mode.

We need to include the following java option in the server startup parameters

-Dcom.adobe.idp.dsc.DSCManager.StartupInMaintenanceMode=true

This variable is set to false by default. The only way to exit the maintenance mode, once started through the JVM argument, is to shut down the document server and remove the JVM argument and start the server again.

One has to exercise caution with JVM argument mode, we should explicitly remove this variable after we are done with maintenance activity otherwise on the next restart the server will keep on coming up with maintenance mode active.

As stated at this link, ADEP Document Services 10.0 offers a feature to operate in a safe backup mode so that the users can take a hot backup of the Document Server without affecting any of its functionality.

We recommend the users to take backups of the database as recommended in its corresponding documentation. Here are the steps to successfully accomplish a manual hot backup and restore of an Oracle11gR2 database without using the RMAN utility. The database can continue to operate without the need to shut down while a successful ‘point in time’ backup is obtained.

Pre-requisites–

Perform the following steps to set up your database for a backup operation

1. Determine the location of your database. For example, in oracle 11gR2 default install location for a database instance with SID=UPGRADE would be:

C:\app\<username>\oradata\UPGRADE

2. Database comprises of control files, redo log files, Data files

3. Locate the pfile and spfile of your database instance, and back them up if necessary. (refer to this link)

4. Connect to your database instance using sqlplus. Run the following command on the command prompt

C:\>sqlplus / as sysdba

5. Run the following query on the SQL Plus syntax to determine if you are connected to the right database

Query: Select name from v$database;

Set up the database to be able to perform a hot backup–
1. Check if the database is in archivelogmode

Query: Select log_mode from v$database;

2. If the database is not in archivelogmode then put the database in the archive log mode

a.) View the location where the archive logs would be written

Query: show parameter log_archive_dest_1;

b.) Set the value of this parameter to a desired location

Query: alter system set log_archive_dest_1=’LOCATION=<path to desired directory>’ scope=spfile;

Example: alter system set log_archive_dest_1=’LOCATION=c:\my_directory_for_logfiles’ scope=spfile;

c.) Shutdown the database

Query: shutdown immediate;

d.) Start database in mount mode

Query: startup mount;

e.) Alter the database to start archive logging

Query: Alter database archivelog;

f.) Open the database so that it is available for transactions

Query: Alter database open;

g.) Verify that the database is in archivelogmode

Query: select log_mode from v$database;

h.) View other details of the archive logging

Query: Archive log list;

Note- One can switch the current archive log by executing the command

Query: Alter system archive log current;

Taking a hot backup–

Now that we have prepared our database for a hot backup, we can go ahead with actually backing up the files.

Follow the following steps to take hot backup of the tablespaces

1. Find out the number of tablespaces associated with the database

Query: Select tablespace_name from dba_tablespaces;

The output is a list which contains names of tablespaces you will need to backup for the whole database.

2. Find out if the tablespaces are ready for hot backup

Query: Run select * from v$backup;

If the output says not active then it is not in hot backup mode

Note- Make sure that the database is in archivelog mode before trying to attempt this. You cannot take a hot backup of your tablespaces unless your database is operating in the archive log mode

3. Put the tablespaces in hot backup mode

Query: Alter database begin backup;

Query: Select * from v$backup;

Now the output should say active.

4. Copy the tablespace files on the hard drive to the backup location.

5. Put the tablespaces out of the backupmode

Query: Alter database end backup;

6. Verify that the tablespaces indeed have come out of the backup mode

Query: Select * from v$backup;

7. Switch the archive log

Query: Alter system archive log current;

8. Backup the control file

Note- Don’t use the operating system’s copy command to do this

Query: Alter database backup controlfile to ‘<path>\ backup filename’

9. Copy the archive logs to the backup location

Backup of the database finished.

Restoring the oracle database from a hot backup

1. Copy the tablespace files from the backup location to the installation directory of the database instance. Also copy thecontrolfilebackup.

2. Rename it to CONTROL01.CTL as it was earlier.

Note- If you had another copy of the control file with the name CONTROL02.CTL, then just create a second copy of the CONTROL01.CTL and rename it CONTROL02.CTL

3. DO NOT COPY OR restore the REDO logs. If the REDO logs from the previous backup period persist then delete them

4. Start the database in mount mode

Query: startup mount;

5. Recover your database using the following

Query: Recover database until cancel using backup controlfile;

Note- the oracle system will suggest an ‘archive log file name’ to use for recovery, if you have copied the backup logs to the same location which was being used for storing the logs by the database, then u can just keep on pressing enter. Or you may give the full path to the log file.

6. When you have applied all the logs that you had used to take the backup, then write cancel on the prompt and press enter.

7. The transaction logs have been applied. Run the following query to open the database for transactions.