|
|
|
Reinstallation of K2 gaia
|
|
|
Introduction
You will get acquainted with the graphical form of individual steps of reinstallation in the form of a diagram.
|
|
|
Dictionary of terms
Reinstall Manager is a feature of K2 that helps with the reinstallation of K2.
Licence administration is a feature of K2 that is used in this document to remotely log off users from K2.
SQL Server Management Studio (SSMS) is a Microsoft® product that is used to manage MS SQL servers and databases.
Oracle SQL Developer is an Oracle Corporation® product that is used to manage Oracle servers and databases.
Reinstallation of build type - small is the type of reinstallation, when only the last number of the version, the so-called build, is changed. This type should only solve bug fixes and add minor improvements. This reinstallation should not endanger the existing functionality. No identifiers that are used in scripts are removed unless they are evaluated as incorrect. As an example, we will give the omission of canceling the identifier when upgrading to a higher release or generation version. Then the use may result in unwanted behavior or an algorithm error.
Reinstallation of the release type - medium is a type of reinstallation when the middle number of the version, the so-called release, is changed. New functionalities can be added to individual releases. The same rules apply as in the previous - "small" reinstallation, with the difference that it is advisable to perform a test reinstallation before the reinstallation itself and then test the key functions of K2.
Reinstallation of Generation version type - large is the type of reinstallation when the first number of the version is changed. This is a fundamental change, when completely new functionalities are added to K2 or the existing ones are fundamentally redesigned or canceled. This type always requires reinstallation in a test environment, as situations can occur especially during conversions that cannot be reliably treated in laboratory conditions during development. The reinstallation of the production K2 is thus performed first in the test environment, when the test folder is taken over, and after testing and debugging of all conversions and functionalities, the reinstallation is then performed on the production K2.
The application server (AS) is a non-visual superstructure of K2, which performs automatic tasks, scheduled tasks, communicates with other K2 products, e.g. web services server (SWS), serves web client, etc.
Taking over an existing installation is a state where the folder with the K2 is used for a new installation. This situation should not normally occur because the Windows installation mechanism retains all the msi files, from which it performed the installation, in the system folders and information in the registry until the program is uninstalled. So it follows from the logic of the matter that by constant taking over one K2, the registry will be weeded and the space on the system disk will be reduced by the size of the msi file with each reinstallation. Another consequence is that there are multiple records of installation in the records of the K2 installer, even if there is only one K2. The maximum number of records for K2 instances is 100, and no more instances can be added any more.
When to use takeover?
- When you create a test environment and copy the complete production K2 to the new folder.
- When the installation is performed from a different computer than before. However, be careful because installing from multiple computers in a network environment can cause file inconsistencies.
- When the removing the original K2 during reinstallation was failed.
- If an error occurs during the reinstallation in the installation phase and the installation terminates unexpectedly.
|
|
|
Create a test environment for reinstallation
There are several ways to create a test environment so that a reinstallation can be performed in a folder. The minimum condition for a folder to be considered K2 is the presence of the k2.ini and sysk2.ini files, and the data in them refers to an existing server and database. However, an optimally prepared test environment is performed by creating a copy of sharp databases on database servers, it can be within one SQL server or the data can be transferred to another one, by copying the folder of the sharp K2 to a new folder and by overwriting the link to the database, or the server, in the k2.ini. The copy created in this way is identical to the sharp K2 and thus all possible problems can be solved before reinstalling the sharp K2. Adjustments in the data, which must be done during the test reinstallation, so that, e.g.. conversions take place without errors, can be done, and it is also recommended, in parallel to the test, and in operation.
When creating a test K2, it is a good idea to consider whether you need to transfer all databases or schemas. For test reinstallation, it is advisable to use only databases of sharp clients. There is no need to make copies of DEMO, INIT or test clients. E.g. the sharp K2 contains the following clients: DEMO (demonstration database supplied by K2), INIT (demonstration database supplied by K2), COMPANY (production database), COMPANY2 (production database of another company or branch), COMPANY2_TEST (test database created by a copy of COMPANY2). In this case, only COMPANY and COMPANY2 clients are used for testing purposes. Other databases are not needed. However, if only some databases are copied, you must modify the COMPANY table in the configuration database. This can be done either by directly editing the tables using SQL queries, or by editing the table with a tool such as SSMS, or in database administration in the K2. It is important that the company table only contains records that match the databases used in the test.
|
|
|
Reinstallation procedure
|
|
|
Scheme
scheme is designed so that it can be applied to any situation where it is necessary to reinstall K2.
Picture: K2 reinstallation scheme
The scheme in its main branch shows the reinstallation without any problems on the installed K2.
The other branches, which you will find in chapters Check of required initialization of version Check of all databases structures and Update extensions, come in a non-standard situation.
|
|
|
Colors and shapes of blocks in the scheme
|
The beginning or the end of the scheme or subscheme. |
|
A decision block, when the scheme branches according to the specified condition. |
|
A block of the process. Performing an action. |
|
A block of the subprocess. A subprocess contains a subschema that contains multiple actions. |
|
Indicator of the direction of the scheme, including the result of the decision when this branch occurs. |
|
|
|
Use of the scheme
The scheme in its main branch shows the reinstallation without any problems on the installed K2.
Other branches come in a non-standard situation. Non-standard situations are understood when the reinstallation has been performed only partially, there was a problem during the removal of the previous version, a copy of the production K2 was created in order to test the reinstallation, etc.
|
|
|
Individual steps of reinstallation
In order for the diagram to be complete, it is necessary to explain each step of the reinstallation. You will learn what needs to be done at each level, what are the troubleshooting options, or where you can find support resources to solve the problem.
|
|
|
Decision making: Is the executable K2 available?
Decisive person: IS K2 administrator
Description: Executable K2 means the state when the complete K2 is located in the folder, which can be executed and can be worked on. At this point, it does not matter whether the folder was created by the installation or copied from the operating K2 as a copy. If the K2 is executable, continue with the point Plan the reinstallation, if it is not, continue with the point Decision making: The databases are identical to the installed K2 version.
|
|
|
Log off all users
Location: Information system K2
Start: IS K2 administrator
Authorization: Right - Administrator/General/Service actions (right number 1)
Condition: A mandatory action - cannot be reinstalled if users are logged in to K2
Description: All K2 users must be logged out before the reinstallation. Their list and the possibility to log out can then be found in the "License Administration", which is available in the "Administrator / System / License Administration" menu or as the function number 678.
Picture: Licence administration and logged-in users
To log off the user, open the record detail and press the "Log off" button. Advantageously, running application servers can be shut down in this way without the need to connect to computers where the AS is running.
Picture: The logout users from the K2
Note
It is up to the administrator whether to disconnect the user directly from the form or to find out for each person in person if they have any records in progress. By pressing "Log off" button a user will be logged off without saving records in progress.
There may be situation where the user cannot log out under any circumstances and, in addition, it is found that the user does definitely not have the running K2. In this case, you need to "kill" the session on the SQL server. To find users on MS SQL, the sp_who command is used, which lists the table with existing connections to the server.
Picture: List of connections with MS SQL server
To terminate the relevant connection, it is necessary to know which database the user, who is not logged-out, is connecting to. Usually there are one or two records in the statement, depending on how many connections remain "hanging". The spid, status, loginame, hostname, dbname, and cmd columns are important. The spid column is the connection number we need to know to terminate it, status is the connection status, loginame is the user under which K2 logs into the database, hostname is the name of the computer from which K2 is or was started, dbname is or are the names of databases, to which K2 is connected and cmd is the command that is currently being executed. For safe termination the login, the status column should be in the sleeping state and cmd AWAITING COMMAND. The other previously listed columns must match the credentials and names of the unlogged-off user to disconnect the correct connection. The kill command is used for this, where the number of the connection we want to terminate is entered: kill 64.
Th following queries are used on Oracle:
select SID, SERIAL#, CLIENT_INFO, TERMINAL, LOGON_TIME FROM "SYS"."GV_$SESSION"
where USERNAME='K2' AND REGEXP_LIKE("CLIENT_INFO", 'K2/./.*/.*/.*/.*/.*')
order by TERMINAL
and
alter system kill session '19,46574';
For the kill command, the session values are 'SID, SERIAL #'.
|
|
|
Backup all databases
Location: Database Management Tool (SQL Server Management Studio)
Start: IS K2 administrator
Authorization: According to the permissions set on the SQL server
Condition: An optional action, this is a manufacturer's recommendation
Description: Before each reinstallation, the administrator should back up all databases that are affected by the reinstallation. It is a system database K2 - CONF and all company databases. Other databases such as INIT and DEMO do not need to be backed up. Backups can then be used in the event that an error occurs during the reinstallation, when it is necessary to return the K2 installation to its original state before the reinstallation. When it is necessary to restore the backup will be described in the next steps of the reinstallation.
Note
We use various client tools for database operations. For Microsoft, it is recommended to use Microsoft SQL Server Management Studio (SSMS). For Oracle, for example, data pumps or Oracle Recovery Manager (RMAN) are used.
|
|
|
Reinstall manager - preparing to reinstall
Picture: Pre-installation preparation
Location: Information system K2
Start: IS K2 administrator
Authorization: Right - Administrator/General/Service actions (right number 1)
Condition: A mandatory action - cannot be reinstalled if K2 is not set in reinstallation mode
Description: The Reinstall manager is primarily used to set K2 to the so-called reinstallation mode. This is a situation where it is ensured that no users are logged in to the K2, new users cannot log in, and it is also true that K2 has passed all the checks that are implemented for the given version. The individual actions that are performed in the Reinstall manager are described in the following chapters.
Was it performed?
First of all, it is necessary to check whether there is a so-called "Pre-installation preparation" in the default version. These are operations that must be performed before the actual reinstallation to a higher version. If the preparation is not performed, it is not possible to reinstall.
If a higher generation version is not installed, the pre-installation preparation will not start!
Note
If a pre-installation preparation exists, there is a button with the given information on the form.
Picture: Reinstall manager - Pre-installation preparation
If there is a pre-installation preparation and it has not been performed, continue with the next point Perform pre-installation preparation. If it does not exist, you can continue with the point Check of required initialization of version for all databases.
|
|
|
Perform pre-installation preparation
Location: Information system K2
Start: IS K2 administrator
Authorization: Right - Administrator/General/Service actions (right number 1)
Condition: The required action if upgrading to a higher generation version - you cannot set the reinstall mode if it did not perform
Description: If there is a pre-installation preparation, it is necessary to apply it to the default version. Press the button to display the form with more detailed information or inputs for preparation.
Picture: Example of a pre-installation preparation
Note
Successful completion of the pre-installation preparation is one of the conditions for the upgrade to a higher generation version and is checked only by the installer, because only the installer knows for sure how "big" the reinstallation is.
|
|
|
Perform required initializations in clients where they are missing
Location: Information system K2
Start: IS K2 administrator
Authorization: Right - Administrator/General/Initialization of version (right number 755)
Condition: Mandatory action - you cannot set the reinstall mode unless all required initializations have been performed
Description: The start of required initializations is available in the "Administrator / Initialize version" menu or via the function 552. Then continue by pressing the "Required" button in the form. After successful initialization, we can return to the step Check of required initialization of version through all databases, which will perform a recheck.
Picture: Starting the required initialization
Note
If the initialization is not successful, it is necessary to report the problem to K2. To solve the problem faster, it is advisable to log the manifestation of the error to a file, according to the instructions in the K2 technical documentation. In some cases, there may be an error in the initialization that is fixed in a higher build version. If it is a reinstallation of the build type, then the missing initialization can be ignored because the error is fixed and the initialization will be performed during the reinstallation. It is up to the user whether to ignore the check because he/she knows he/she will not reinstall to a higher release or generation version. If the check is ignored and nevertheless, the reinstallation to a higher release or generation version is performed, the instalator will draw attention to this situation and will not allow the ignoration any more.
|
|
|
Backup all databases 2
After repairing the database structures, it is recommended to back up those that have been affected. The step is defined in the point - Backup all databases. Continue with the point Check disk space (C, installation, database).
|
|
|
Decision making: The databases are identical to the installed K2 version
Start: IS K2 administrator
Description: This is the decision step to which we will get if the executable K2 is not available. See the Decision making: Is the executable K2 available?
If we have backups from the version that correspond to the installed version of K2 or from that it is possible to perform conversions to the installed version and at the same time there are k2.ini and sysk2.ini files with the correct values ??in the folder where we want to install, such a K2 torso can be considered a version to which it can be reinstalled. Further continue with the Decision Making step: Are there database backups?, otherwise we must take a step Restore databases from a backup.
A database restore is performed in the cases when errors occurred during the installation, especially in the SQL conversion section. Depending on the extent of the errors, it is possible either fix these errors or restore the database and solve the problems in the previous version so that the next conversion takes place properly. It is advisable to solve possible fixes with the technical department of K2. On the one hand, the correction may seem trivial, but it is followed by other logic, which could have taken place without an error message, but due to a previous error, it worked with bad data. Another reason is that the error did not appear during testing, but only on specific customer data.
|
|
|
Decision making: Are there database backups?
Start: IS K2 administrator
Description: In this decision step, we decide whether it is necessary to make database backups and we can continue with the step Restore databases from a backup or whether the backups are needed to made and then we continue with step Backup all databases 2.
|
|
|
Restore databases from a backup
Location: The database management tool
Start: IS K2 administrator
Description: The step is performed using the database management tools that allow you to make database backups and which were mentioned in the Backup all databases step.
|
|
|
Check disk space (C, installation, database)
Location: OS Windows
Start: IS K2 administrator
Authorization: Administrator authorization to administer the computer for the installation of K2 and the database server
Condition: Optional operation. This is a manufacturer's recommendation. It is advisable to prevent situations where on any of the affected disks runs out the space during the installation of K2.
Description: To avoid problems with insufficient disk space when reinstalling the K2, it is recommended to check the amount of free space on all affected disks. This is especially the C drive on the computer where the K2 is installed. The MSI file is copied to this system disk as installation media before reinstallation. This installation package is stored in the temporary Windows directories after reinstallation until the K2 is uninstalled.
If the K2 is installed on a disk other than the system disk, it is advisable to perform a check also in this location before the reinstallation.
The last place is the disks for databases directly on the SQL server. During the reinstallation, we work with databases, for example, data is imported, structures are converted, etc., so it is advisable to make the check here as well.
Note
The amount of space required on each disk depends on the size of the installation media and also on the size of the database. In some cases, a check, whether there is enough free space, is made, for example when starting the installation. There are situations when the check cannot be performed. It is therefore recommended to always check this information.
|
|
|
Start the reinstallation
Location: K2 Installer
Start: IS K2 administrator
Authorization: Administrator authorization to install applications on the given computer
Condition: The current version supports the upgrade to the selected newer version.
Picture: Records with K2 installations
The reinstallation can be done in two modes.
The first is the classic reinstallation, when there is a complete functional K2 version, which is available in the K2 installer on the "Installed" tab, see the Picture: Records with K2 installations. Above this installation, the update to the new version will start.
In the second case, it is a so-called new installation by taking over an existing K2 installation. This procedure involves a new installation, including the creation of a new entry in the K2 installer after a successful installation. This update is very similar to the classic variant, except that it is used in the following cases:
We only have a "torso" from the current K2 installation
This means that we do not have K2 binaries available, there are only data files, databases, configuration files, etc. The so-called a "torso" can be created, for example, after uninstalling K2. This state can occur, among other things, in a situation where the uninstallation takes place within the update and after the uninstallation itself, an error occurs during the subsequent update. In this case, the K2 remains in a state where it cannot be started and only data and configuration files remain on the disk.
There is no installation record in the K2 installer
The another reason is the missing installation record. In this case, we can not run the update because this option is not available. This can happen, for example, when the installation is being migrated to another server, or we need to reinstall from a different computer than before.
Note
We will use this installation in all cases where we do not have binary files available or there is no installation record.
Note
If we update the K2 in this way, when the situation does not require it, the installation will be OK, but the installation records will accumulate on the "Installed" tab in the K2 Installer and the installation files ("msi"), which the system uses for uninstallation, will accumulate in the Windows system. When we then run the uninstall over any duplicate entry in the K2 installer, the files are removed from the K2 directory, K2 will not be executable, and one installation file is released from the operating system. Other entries in the system remain as inconsistent data, including the remains of the installation file in the Windows system. Please note that each such file takes up about 1.7 GB of data. It is therefore recommended to perform the K2 updates in the form of a classic update over an existing entry on the "Installed" tab in the K2 Installer.
After evaluating the status of the installation, it is necessary to decide how we will continue. If it is necessary to perform a new installation as a so-called "takeover", continue with the Decision making: Is the executable K2 available? If a reinstallation can be performed in the standard way, then continue with the point Start the reinstallation.
Description
To upgrade to a newer version, there must be an entry with the current version, on which the update will start, in the K2 Installer.
The second condition is that the current version can be updated to the selected newer version. We will verify this fact by selecting the version to update in the K2 Installer. For the installation record, you can select the version in the drop-down menu in the "Installation" column. If no version is available in the menu, it probably may not be possible to update the current version to a newer version that is part of the K2 Installer.
If it is not available a version to select, it is possible to hover the mouse over the "?" on the right side of the installation record and the K2 installer displays information about the current installation, including why no version was offered. This makes it possible to find out over which version the user must update to continue.
Note
The K2 installer works in two modes. In the first mode, the K2 Installer is part of a zip archive with a specific K2 version downloaded from the K2 info service. In this case, only the option to update to the version for which the archive is intended is available. Thus, there will be one version or none in the offer to update, depending on the condition.
In the second mode, the K2 Installer is installed on the computer used for installations, the user logs on to the K2 FTP server after launch and has all currently released versions of K2 and other products available. In this case, there will be a version in the "Installation" drop-down menu, to which the given installation can be updated.
To start the K2 update, select the version and click on the "Execute" button in the installation record of the K2 Installer.
The installation continues with the next step.
|
|
|
Decision making: Is there an original K2?
Location: K2 Installer
Start: K2 Installer
Description: There is an executable K2 in the folder specified by the installer or selected during installation. If so, the checks of required initializations of version and checks of database structures are performed automatically. The procedure and possible corrections are described in the points Check of required initializations of version through all databases and Check of all databases structures.
|
|
|
Decision making: Is there a record in the K2 installer?
Location: K2 Installer
Start: K2 Installer
Description: This decision is made internally in the K2 installer and the user does not interfere in this decision. A record in the installer means that the installation was started from the Installed page, see the Picture: Records with K2 installations. If such a record exists, proceed to the next step, otherwise it continues to Install the new version files.
|
|
|
Remove an existing K2 installation
Location: K2 Installer
Start: K2 Installer Wizard (MSI file)
Description: The first step that the K2 Installer performs when updating K2 in the standard way is to remove the existing installation. This process removes all files that have been installed. The files that have not been added by installation, remain in the installation directory. If any file from the installation is modified, so it does not correspond to the file that was installed, it is also left by the Installer.
|
|
|
Decision making: Removal OK?
An error may occur when removing the original installation. Likewise, an error may occur in the next step when a new installation is started. If this happens, we are in a state where we do not have the K2 installation because it was removed, so we do not have a record to run the update that ended with an error.
If the removal of the installation was successful and the new installation has started, continue with the step Install the new version files.
If the removal or a subsequent update failed and the existing installation was removed, we return to the beginning of the reinstallation and continue with the point: Decision making: Is the executable K2 available? or we can terminate the installation process, but the K2 will not be available at this time.
|
|
|
Install the new version files
Location: K2 Installer
Start: K2 Installer Wizard (MSI file)
Description: The new installation is started after the successful removal of the previous installation, or if we update K2 by taking over the existing installation. In this step, the new files that are part of the K2 installation will be copied. After a successful copying, an installation record is created in the OS Windows.
After the successfully files copying, the update automatically continues with the next step, which cannot be influenced by the user. This is the SQL conversion step.
|
|
|
SQL conversion
Location: K2 Installer
Start: K2 Installer Wizard (MSI file)
Description: At this stage, the K2 installer runs the files with SQL conversion scripts which convert the database structure for the new version. Depending on what update it is, a different number of files are run.
The following table summarizes the list of files that run depending on the database platform and also on the scope of the update. In case of an upgrade to a new version, for example K2 mia › K2 luna, all these files are run. In minor updates, only some files are run.
File |
Platform |
Description |
New version |
New release |
New build |
K2_C2020.sql |
MS SQL |
CONF database |
X |
|
|
K2_C2020Ora.sql |
Oracle |
CONF database |
X |
|
|
K2_C2020Additional.sql |
MS SQL |
CONF database |
X |
X |
X |
K2_C2020OraAdditional.sql |
Oracle |
CONF database |
X |
X |
X |
K2_D2020.sql |
MS SQL |
company database |
X |
|
|
K2_D2020Ora.sql |
Oracle |
company database |
X |
|
|
K2_D2020Additional.sql |
MS SQL |
company database |
X |
X |
X |
K2_D2020OraAdditional.sql |
Oracle |
company database |
X |
X |
X |
In the conversion files that run when new version, it is a one-time, non-repeatable conversion. In these cases, there are large conversions which involve the transfer of data and so on. Such operations can no longer be re-run. This could damage database structures or cause inconsistencies in data.
Other conversion files are always run. These are usually operations such as adding a new field to a database table, new table, etc. These files are ready to be run again without the risk of damaging the database or its consistency.
If an error occurs during the conversion, each error is written to the output file "sql_inst.log", which is located directly in the K2 installation directory. If there is an error, this file is displayed to the user at the end of the conversion.
Note
If an error occurs during the update after the conversion has been made and the entire update needs to be performed again, the databases must first be restored from the backup. This is only a state where conversions are triggered that cannot be run repeatedly, see the table above. If the database was backed up only before the entire reinstallation and not after all the checks, you will need to install or restore the original K2 file system from the backup in order to perform all the checks and preparations.
After performing the database conversions, the update continues with the point Required initialization part 2/2.
|
|
|
Required initialization part 1/2
Location: K2 Installer
Start: K2 Installer Wizard (MSI file)
Description: As part of the required initializations of phase 1, only corrections of structures are performed, which could not be performed by running some sql script.
|
|
|
Decision making: Was there an original K2 exe?
Location: K2 Installer
Start: K2 Installer Wizard (MSI file)
Description: If the k2.exe startup file was missing in the folder where the new K2 is installed, and therefore the structure checks could not be performed before the reinstallation, these checks will be performed now. If the checks have already been run on the original K2, continue without these checks to the step Update extensions.
|
|
|
Data import
Location: K2 Installer
Start: K2 Installer Wizard (MSI file)
Description: New data for DEMO and INIT system clients are imported into the K2. Furthermore, system records for various tables are imported into all clients and the standard scripts are being updated.
|
|
|
Required initialization part 2/2
Location: K2 Installer
Start: K2 Installer Wizard (MSI file)
Description: This part of the installation performs actions that could not be performed within conversions, or that require K2 logic, or for which a new script is required.
|
|
|
Import license
Location: K2 Installer
Start: K2 Installer Wizard (MSI file)
Description: A new license is imported into K2 from the file that was selected during installation. This import is performed only when reinstalling the version or takeover of the installation.