Upgrade Readiness tool checks for the following

Environment-

1. Operating system – Checks if the current operating system supports Document Server.
2. Application Server version- Checks if the current application server version hosting LiveCycle is fit for hosting Document Services.
3. RAM- Checks the amount of RAM
4. JDK- Checks the version of the JDK needed
5. Database driver and database version

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

1. LiveCycle 7 compatibility layer version.
2. Presence of QPAC based processes
3. Presence of BAM (no longer supported in ADEP Document Services 10.0)
4. 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

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

curl -u <admin username>:<password> -f -o progress.txt -F action=add -F zipFileName=<backupFileName.zip> -F installDir=<path to installation directory> -F targetDir=<path to backup directory> “http://<hostname>:<port>/crx/config/backup.jsp”

an example of the above command is following

curl -u admin:admin -f -o progress.txt -F action=add -F zipFileName=backup.zip -F installDir=c:/CRX -F targetDir=c:/backup “http://myhost:4502/crx/config/backup.jsp”

This creates a zip file backup of the repository with file name ‘backup.zip’ at the location ‘c:\backup\backup.zip’

For more information on the backup/restore refer to the following  link

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

1. Servlet commands-

Refer to the following link to know about the servlet commands.

Note- Servlet commands work only when the document server is running.

2. JVM argument-

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 the controlfilebackup.

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.

              Query: Alter database open resetlogs;

Restore complete