Solution
The ESSBASE.SEC file contains the Essbase security filters, the list of Essbase native users, and all Substitution variables defined for this Essbase server. It does not contain anything stored in the outline, such as members and their hierarchy, or member formulas. Nor does it contain actual data, which is stored in the .ind and .pag files.
From a Planning perspective there are two concerns with restoring or recreating the SEC file: (1) the substitution variables and (2) the Essbase supervisor user's username and password.
In addition, remember that there may be non-Planning, “native” Essbase applications on the same server, and security for these will also be managed by the SEC file. However, whilst a Planning application stores a copy of the Essbase security filters in its relational database, the filters for Essbase native applications only exist in the SEC file. If there is a mix of Planning and native Essbase applications on the same Essbase server, consider restoring the SEC file from an earlier backup rather than recreating it. If only Planning applications are present on the server the downside to recreating the SEC file is much smaller.
Symptoms of SEC file corruption:
1) Essbase will not start
2) Essbase starts but unexpectedly exits
3) Essbase cannot be refreshed from Planning with “Security Filters” option Checked. Note there are other reasons this can occur.
4) Other potential stability issues. You are most likely to see errors at startup, so always start Essbase in the foreground to see if it starts without errors.
Three options are presented below - restoring the .bak file, restoring an older backup, or recreating the Essbase SEC file altogether.
I. Restore a backup
Stop Essbase. Navigate to \Hyperion\AnalyticServices\bin (9.2.x and 9.3.x) or \Hyperion\products\Essbase\EssbaseServer\bin (11.1.1.x) and locate ESSBASE.SEC (the SEC file) and ESSBASE.BAK. Rename these files, turning ESSBASE.BAK into ESSBASE.SEC and backing up the original ESSBASE.SEC.
Now start Essbase in the foreground and test to see if the issue is resolved.
II. Restore from an older backup
Many customers have backups of the SEC file stretching back days or weeks. Restore one of these older backups using the same procedure as above (renaming your backup ESSBASE.SEC). This is an appealing option if there are native Essbase applications on the server. After restoring a working SEC file, run a Planning refresh with the “Security Filters” option checked for each Planning application to update the restored SEC file with the latest filters as they exist in the Planning applications.
III. Recreate
Before you start, make a record of the substitution variables. If you are lucky enough to be able to start Essbase you can run a dump of the SEC file. Start Essbase in the foreground. Then type:
DUMP C:\SomeDirectory\DumpFile.txt
The path and filename are up to you, but the directory should exist. This will dump a copy of the SEC file which has a section listing the substitution variables.
Another alternative is to view the variables in the AAS/EAS console and take a screenshot.
If Essbase does not start you have no way to get this information. If the list of variables is crucial you can go back to an old SEC file, dump that, and at least have a partial list.
Rebuild Procedure:
1. Check you have a backup of substitution variables and data.
2. Stop Essbase.
3. Delete the existing Analytic Server Project in Shared Services, or just the affected server if you have multiple Analytic Servers registered. Right-click on the Project > Delete.
4. Back up 5 files from \Hyperion\AnalyticServices\bin (9.2.x and 9.3.x) or \Hyperion\products\Essbase\EssbaseServer\bin (11.1.1.x)
ESSBASE.SEC
ESSBASE.BAK
ESSBASE.BAK_startup
ESSBASE.BAK_preUPM
ESSBASE.BAK_postUPM)
You may only have 3 of these files if Essbase was never previously externalized.
5. Delete these 5 files from \Hyperion\AnalyticServices\bin (9.2.x and 9.3.x) or \Hyperion\products\Essbase\EssbaseServer\bin (11.1.1.x)
6. Launch Essbase in the foreground (Start > Run > cmd > essbase)
7. When prompted for a new username and password for the Essbase supervisor user, use the same username and password as previously if at all possible. If you change the username or password you will have to make changes elsewhere (Planning DSNs/datasources, etc…).
8. Essbase should start successfully and say “Waiting for client requests”. A new SEC file will have been created.
9. Log into the AAS/EAS console. Add the Analytic Server if it isn’t already visible. Use the supervisor user you just started Essbase with to make the connection between EAS and Essbase.
10. Your existing applications will most likely not be visible in the list of applications under the Analytic Server. Don’t worry - the applications are still there. To restore them you will need to create “new” applications with the same names:
Right-click on Applications > Create applications > Using block storage (and not using Unicode). The application name you enter must be exactly the same as your existing app (including the case) for this procedure to pick up the application in the file system.
You can check application names by looking at the directory names under \Hyperion\AnalyticServices\app. Each app has a folder named after it.
Repeat this procedure for all apps that had disappeared from the list. Planning apps are always Block Storage (BSO).
11. Externalize Essbase. Right-click on Security > Externalize Users. If in doubt, choose the bottom option and put in the same password as you used in step 6 as the password. After externalizing, check you can see your Analytic Server Project in Shared Services.
12. Log into the Planning Desktop (or Planning web in 9.3 and above). Run a database refresh. Do this in two parts – refresh the database, then refresh the security filters.
13. Recreate your substitution variables
The ESSBASE.SEC file contains the Essbase security filters, the list of Essbase native users, and all Substitution variables defined for this Essbase server. It does not contain anything stored in the outline, such as members and their hierarchy, or member formulas. Nor does it contain actual data, which is stored in the .ind and .pag files.
From a Planning perspective there are two concerns with restoring or recreating the SEC file: (1) the substitution variables and (2) the Essbase supervisor user's username and password.
In addition, remember that there may be non-Planning, “native” Essbase applications on the same server, and security for these will also be managed by the SEC file. However, whilst a Planning application stores a copy of the Essbase security filters in its relational database, the filters for Essbase native applications only exist in the SEC file. If there is a mix of Planning and native Essbase applications on the same Essbase server, consider restoring the SEC file from an earlier backup rather than recreating it. If only Planning applications are present on the server the downside to recreating the SEC file is much smaller.
Symptoms of SEC file corruption:
1) Essbase will not start
2) Essbase starts but unexpectedly exits
3) Essbase cannot be refreshed from Planning with “Security Filters” option Checked. Note there are other reasons this can occur.
4) Other potential stability issues. You are most likely to see errors at startup, so always start Essbase in the foreground to see if it starts without errors.
Three options are presented below - restoring the .bak file, restoring an older backup, or recreating the Essbase SEC file altogether.
I. Restore a backup
Stop Essbase. Navigate to \Hyperion\AnalyticServices\bin (9.2.x and 9.3.x) or \Hyperion\products\Essbase\EssbaseServer\bin (11.1.1.x) and locate ESSBASE.SEC (the SEC file) and ESSBASE.BAK. Rename these files, turning ESSBASE.BAK into ESSBASE.SEC and backing up the original ESSBASE.SEC.
Now start Essbase in the foreground and test to see if the issue is resolved.
II. Restore from an older backup
Many customers have backups of the SEC file stretching back days or weeks. Restore one of these older backups using the same procedure as above (renaming your backup ESSBASE.SEC). This is an appealing option if there are native Essbase applications on the server. After restoring a working SEC file, run a Planning refresh with the “Security Filters” option checked for each Planning application to update the restored SEC file with the latest filters as they exist in the Planning applications.
III. Recreate
Before you start, make a record of the substitution variables. If you are lucky enough to be able to start Essbase you can run a dump of the SEC file. Start Essbase in the foreground. Then type:
DUMP C:\SomeDirectory\DumpFile.txt
The path and filename are up to you, but the directory should exist. This will dump a copy of the SEC file which has a section listing the substitution variables.
Another alternative is to view the variables in the AAS/EAS console and take a screenshot.
If Essbase does not start you have no way to get this information. If the list of variables is crucial you can go back to an old SEC file, dump that, and at least have a partial list.
Rebuild Procedure:
1. Check you have a backup of substitution variables and data.
2. Stop Essbase.
3. Delete the existing Analytic Server Project in Shared Services, or just the affected server if you have multiple Analytic Servers registered. Right-click on the Project > Delete.
4. Back up 5 files from \Hyperion\AnalyticServices\bin (9.2.x and 9.3.x) or \Hyperion\products\Essbase\EssbaseServer\bin (11.1.1.x)
ESSBASE.SEC
ESSBASE.BAK
ESSBASE.BAK_startup
ESSBASE.BAK_preUPM
ESSBASE.BAK_postUPM)
You may only have 3 of these files if Essbase was never previously externalized.
5. Delete these 5 files from \Hyperion\AnalyticServices\bin (9.2.x and 9.3.x) or \Hyperion\products\Essbase\EssbaseServer\bin (11.1.1.x)
6. Launch Essbase in the foreground (Start > Run > cmd > essbase)
7. When prompted for a new username and password for the Essbase supervisor user, use the same username and password as previously if at all possible. If you change the username or password you will have to make changes elsewhere (Planning DSNs/datasources, etc…).
8. Essbase should start successfully and say “Waiting for client requests”. A new SEC file will have been created.
9. Log into the AAS/EAS console. Add the Analytic Server if it isn’t already visible. Use the supervisor user you just started Essbase with to make the connection between EAS and Essbase.
10. Your existing applications will most likely not be visible in the list of applications under the Analytic Server. Don’t worry - the applications are still there. To restore them you will need to create “new” applications with the same names:
Right-click on Applications > Create applications > Using block storage (and not using Unicode). The application name you enter must be exactly the same as your existing app (including the case) for this procedure to pick up the application in the file system.
You can check application names by looking at the directory names under \Hyperion\AnalyticServices\app. Each app has a folder named after it.
Repeat this procedure for all apps that had disappeared from the list. Planning apps are always Block Storage (BSO).
11. Externalize Essbase. Right-click on Security > Externalize Users. If in doubt, choose the bottom option and put in the same password as you used in step 6 as the password. After externalizing, check you can see your Analytic Server Project in Shared Services.
12. Log into the Planning Desktop (or Planning web in 9.3 and above). Run a database refresh. Do this in two parts – refresh the database, then refresh the security filters.
13. Recreate your substitution variables
No comments:
Post a Comment