Skip to end of metadata
Go to start of metadata

WIKI BY MURAT YURUK

CAPTURING INFORMATION ON IMPLEMENTATION ENVIRONMENT-RELATED ISSUES BPC ADMINISTRATORS MAY ENCOUNTER WHILE RESTORING A BPC-MS 7.X TO BPC-MS 10 SYSTEM

The suggestions on this document apply to situations where a BPC Administrator observes a not-by-design behavior during a restore on a newly built BPC10 environment. In most cases, environment-specific issues require consultancy level engagement so the suggestions in this paper are intended to obtain more information about the behavior prior to engaging consultancy services.

Scenario

-        Restore an Appset from the backup files generated in the original BPC MS 7.0 +SQL2005 environment onto a newly installed multi-server BPC MS 10.0 + SQL 2012 solution.

Assumptions

-        BPC10 implementation has system has been freshly installed as per the installation guide.

-        BPC10 Server Manager Diagnostics indicates no errors

-        BPC10 BPCSYSADMIN account has all the privileges setup (as per installation guide) on the network and local servers

-        BPC10 Only static port numbers are being used and non are blocked at any time

-        BPC10 Environment Shell  is available and tasks of copying an environment and processing a cube completes without errors

-        BPC10 Server event logs (Appserver and SQL) indicate no errors relevant to stability of BPC application or the system.

-        BPC10 Both Appserver and the SQL server are located on the same segment of the network

-        SQL Server service and OLAP Server services have read/write privileges on the SQL server

  

Observations

Issue 1- The system will not restore from a SQL.BAK file that is stored locally on the Application Server. However, the file is  saved (on the Appserver) SQL.BAK file (throws error) but instead when this file is placed on the SQL server and the checkbox (Remote SQL Server Path) is checked, it accepts this and allows to move to the next step.

 Cannot open Backup device \\myservername\SQLShare\mySQLRestorefile.bak Operating system error 53 (the network path was not found). RESTORE FILELIST is terminating abnormally.

Recommendations : In this case, notice that the path is changed from what was specified locally. By looking at the path, and running a 3rd party file monitoring tool on the SQLShare path mentioned in the error, we can determine that that the issue related to BPCSYSADMIN carrying out a read/write check on that remote SQL path_. Error 53 typically is related to rights to a folder so ensure that BPCSYSADMIN account has the admin privileges on both the SQL server and the Appserver across the domain. Check to see if checking the checkbox ‘use the path of backup files on a remote SQL Server’ and placing the .BAK file on the SQL server allows you to go past this point._

 Issue 2- An error "The system cannot resolve the database name. Check that your connection with SQL Server still exists, or use another version of SQL Server" is displayed in Step2 of the restore process.

Recommendations: In this situation  ensure that when moving from Step1 to Step2 in the restore process in Server Manager, the SQL Servername and SQL Instancename as well as the OLAp server name are correctly populated (this uses the values from the ‘Server Options’ in Server Manager). So for SQL server the automatically populated path should look like     Servername\SQL Instancename    If this appears correctly, check to ensure that the port numbers specified are open and the SQL server is actively listening on these ports. Also try to establish a telnet session from Appserver to SQL server on that port.

Check the tbllogs table (in Appserver Database) also Windows event logs for any errors

In addition to this, enable the Server Manager log file and capture a log while reproducing the issue and analyze.

Here are the steps to enable the logs:

-Ensure all existing sessions of ServerManager.exe  are closed (also check task manager and kill if any appearing there).

-Restart the SQLServer service and BPC ServiceManager Service.

-Launch the BPC ServerManager.exe from :\PC_MS\Server Management\  folder   as Administrator  (right click on the executable and click ' Run as Administrator')

-Observe if a servermanager.log file is created in  \PC_MS\Server Management\  folder  

- If not created, reboot the Appserver and follow the above process once more.

- If you have multiple Appservers (ie load-balanced scenario) , try to enable the logs on another Appserver .

Issue 3- In some cases you may have to manually restore the SQL and OLAP Databases. This process involves consultancy level expertise. Also the process outline in on old consultancy document made available for the customers  ‘Manual Porting’

 After Manually restoring the database, when trying to logon to Admin console, the system may prompt an error saying that the Appset must be migrated first. However, when you check the Server Manager’s “migrate environment’ option, you find that the manually restored Appset is not listed

Recommendation : The server manager’s ‘migrate environment’ option retrieves the Environment names from the table tblappsetinfo. Ensure that the parameters for the new appset are entered in this table as well as  in tblappsetserverinfo and tblappsetaccess tables  under the Appserver Database. After this, close the server manager, restart the sqlserver service then run server manager again and choose the  ‘Migrate Environment’ option and the appset should now be listed.

Issue 4- While using the ‘Migrate Environment’ option, during the migration of the above manually restored Appset, you may be prompted to save a migration log file ‘i.e  migration.xml’. On review of the captured log file you may come across error messages as below

  “This package is not supported in this version; the file has been moved to the PackageFiles_Backup folder”

   “Ftp package is not supported in this version; you can add the task using the Microsoft FTP task”

 Recommendation : Please refer to the BPC10 Upgrade Guide (pages  21-24) also the SAP NOTE 1707410

"Planning and Consolidation 10.0 only supports the migration for SQL 2008 SSIS packages. SQL 2005 SSIS packages cannot be run on an SQL 2008 or SQL 2012 environment because Microsoft does not support backward compatibility. However, it is possible to upgrade from SSIS 2005 packages to SSIS 2012 packages, whereas it is not possible to upgrade from SSIS 2005 packages to SSIS 2008 because SQL Server 2008 does not support it. See SAP note 1710266 for more information"

"Planning and Consolidation 10.0 does not support the package included with the legacy FTP task (ImportUsingFTP.dtsx) of the custom tasks. This support is provided by Microsoft." 

  • No labels