Hi Siva,

What type of medium have you defined for this backup is it File type or Pipes. Provide the details of medium_getall and dbm.ebl log files.

provide us with the details also one more thing are you using any 3rd party software for this. if yes do check the settings at the tool end for the configuration for pipe and the server settings.

Let us know the details.

Regards,

Ram

Hi Christophe,

this seems to be a new bug...

We will try to locate the problem. At the moment we suspect that the 'move'-errors are triggered by table access to columns which were added later and were defined with 'NULL' as default value and this value was not yet changed.
This behaviour was part of a perfprmance optimization to only actually enter the default value of an added column once that column is accessed.

To identify all table columns which could potentially be affected, please execute the following SQL query:

select t.schemaname, t.tablename, t.createdate as tables_createdate, t.createtime as tables_createtime, t.alterdate as tables_alterdate, t.altertime as tables_altertime, c.createdate as columns_createdate, c.createtime as columns_createtime, c.alterdate as columns_alterdate, c.altertime as columns_altertime, c.columnname, c.default from tables t, columns c where t.createdate

The next step would then be to use an SQL update command to really enter 'NULL' for all rows in the affected tables - of course we will try to locate the bug in the meantime...

Thorsten

Hello Thorsten,

Thanks for your anwser, however the "where" part of your query is missing. Can you please re-post the query with the missing part?

Thanks and best regards,

Christophe

PS: in the meantime we went back to 7.8

ups, sorry, here is the full query:

select

t.schemaname,

t.tablename,

t.createdate as tables_createdate, t.createtime as tables_createtime,

t.alterdate as tables_alterdate, t.altertime as tables_altertime,

c.createdate as columns_createdate, c.createtime as columns_createtime,

c.alterdate as columns_alterdate, c.altertime as columns_altertime,

c.columnname,

c.default

from tables t, columns c

where t.createdate <= c.createdate and t.createtime < c.createtime and t.tablename = c.tablename and t.schemaname = c.schemaname and t.schemaname = 'your_DB_User' and c.default is null

it is pipe .please find details of medium_getall

for complte data backup we are using templete BackData2

/db2/SID/sapdb/programs/bin/dbmcli on SID>medium_getall

OK

BackLog\mem1    /db2/SID/sapdb/data/files/pipe_mem5     PIPE    LOG     0       8       NO      NO              20120927073425  20120927103249          BACK    0

CompleteF\mem1  /db2/SID/sapdb/data/files/complete      FILE    DATA    0       8       YES     NO              20120927073436  20120927110440          NONE    0

BackData2\mem1  /db2/SID/sapdb/data/files/pipe_mem1     PIPE    DATA    0       8       NO      NO              20150216103203  20150216103203          BACK    0

logF    /db2/SID/sapdb/data/backup/SID_LOG      FILE    LOG     0       8       YES     NO              20150224071028  20150224071028          NONE    0

we are taking backup using tool backint for maxdb and it will store tapes using comvault

please find dbm.ebl logs

*** DBA Action starts:

Timestamp: 20150302000001   Function: sda   Object: DATA

2015-03-02 00:00:01

Setting environment variable 'TEMP' for the directory for temporary files and pipes to default ''.

Using environment variable 'TMP' with value '/var/tmp' as directory for temporary files and pipes.

Using MaxDB Kernel Process.

Using connection to Backint for MaxDB Interface.

2015-03-02 00:00:01

Checking existence and configuration of Backint for MaxDB.

    Using configuration variable 'BSI_ENV' = '/commvault/opt/simpana/SapMaxDbAgent/backint.conf' as path of the configuration fi

    Setting environment variable 'BSI_ENV' for the path of the configuration file of Backint for MaxDB to configuration value '/

    Reading the Backint for MaxDB configuration file '/commvault/opt/simpana/SapMaxDbAgent/backint.conf'.

        Found keyword 'BACKINT' with value '/commvault/opt/simpana/SapMaxDbAgent/backint'.

        Found keyword 'INPUT' with value '/commvault/opt/simpana/SapMaxDbAgent/in'.

        Found keyword 'OUTPUT' with value '/commvault/opt/simpana/SapMaxDbAgent/out'.

        Found keyword 'ERROROUTPUT' with value '/commvault/opt/simpana/SapMaxDbAgent/err'.

        Found keyword 'PARAMETERFILE' with value '/commvault/opt/simpana/SapMaxDbAgent/param'.

        Found keyword 'TIMEOUT_SUCCESS' with value '300'.

        Found keyword 'TIMEOUT_FAILURE' with value '300'.

    Finished reading of the Backint for MaxDB configuration file.

    Using '/commvault/opt/simpana/SapMaxDbAgent/backint' as Backint for MaxDB program.

    Using '/commvault/opt/simpana/SapMaxDbAgent/in' as input file for Backint for MaxDB.

    Using '/commvault/opt/simpana/SapMaxDbAgent/out' as output file for Backint for MaxDB.

    Using '/commvault/opt/simpana/SapMaxDbAgent/err' as error output file for Backint for MaxDB.

    Using '/commvault/opt/simpana/SapMaxDbAgent/param' as parameter file for Backint for MaxDB.

    Using '300' seconds as timeout for Backint for MaxDB in the case of success.

    Using '300' seconds as timeout for Backint for MaxDB in the case of failure.

    Using '/sapdb/SID/data/wrk/SID/dbm.knl' as backup history of a database to migrate.

    Using '/sapdb/SID/data/wrk/SID/dbm.ebf' as external backup history of a database to migrate.

    Checking availability of backups using backint's inquire function.

Check passed successful.

2015-03-02 00:00:01

Checking medium.

Check passed successfully.

2015-03-02 00:00:01

Preparing backup.

    Exporting configuration variable 'LD_LIBRARY_PATH' with value '/commvault/opt/simpana/Base'.

    Exporting configuration variable 'SHLIB_PATH' with value '/commvault/opt/simpana/Base'.

    Setting environment variable 'BI_CALLER' to value 'DBMSRV'.

    Setting environment variable 'BI_REQUEST' to value 'NEW'.

    Setting environment variable 'BI_BACKUP' to value 'FULL'.

    Constructed Backint for MaxDB call '/commvault/opt/simpana/SapMaxDbAgent/backint -u SID -f backup -t file -p /commvault/opt/

    Created temporary file '/commvault/opt/simpana/SapMaxDbAgent/out' as output for Backint for MaxDB.

    Created temporary file '/commvault/opt/simpana/SapMaxDbAgent/err' as error output for Backint for MaxDB.

    Writing '/db2/SID/sapdb/data/files/pipe_mem1 #PIPE' to the input file.

Prepare passed successfully.

2015-03-02 00:00:01

Creating pipes for data transfer.

    Creating pipe '/db2/SID/sapdb/data/files/pipe_mem1' ...

    Done.

All data transfer pipes have been created.

2015-03-02 00:00:01

Starting database action for

     the backup.

    Requesting 'SAVE DATA QUICK TO  '/db2/SID/sapdb/data/files/pipe_mem1' PIPE BLOCKSIZE 8 NO CHECKPOINT MEDIANAME 'BackData2''

The database is working on the request.

2015-03-02 00:00:01

Waiting until database has prepared the backup.

    Asking for state of database.

    2015-03-02 00:00:01 Database is still preparing the backup.

    Waiting 1 second ...

    Done.

    Asking for state of database.

    2015-03-02 00:00:02 Database has finished preparation of the backup.

The database has prepared the backup successfully.

2015-03-02 00:00:02

Starting Backint for MaxDB.

    Starting Backint for MaxDB process '/commvault/opt/simpana/SapMaxDbAgent/backint -u SID -f backup -t file -p /commvault/opt/

    Process was started successfully.

Backint for MaxDB has been started successfully.

2015-03-02 00:00:02

Waiting for end of the backup operation.

    2015-03-02 00:00:02 The backup tool process has finished work with return code 0.

    2015-03-02 00:00:02 The backup tool is not running.

    2015-03-02 00:00:02 The database is working on the request.

    2015-03-02 00:00:02 The database is working on the request.

    2015-03-02 00:00:07 The database is working on the request.

    2015-03-02 00:00:17 The database is working on the request.

    2015-03-02 00:00:32 The database is working on the request.

    2015-03-02 00:00:52 The database is working on the request.

    2015-03-02 00:01:17 The database is working on the request.

    2015-03-02 00:01:47 The database is working on the request.

    2015-03-02 00:02:22 The database is working on the request.

    2015-03-02 00:03:02 The database is working on the request.

    2015-03-02 00:03:47 The database is working on the request.

    2015-03-02 00:04:37 The database is working on the request.

    2015-03-02 00:05:03 Canceling Utility-task after a timeout of 300 seconds elapsed ...

    OK.

    2015-03-02 00:05:04 The database has finished work on the request.

    Receiving a reply from the database kernel.

    Reply from db-kernel:

        SQL-Code              :-903

    End of reply from db-kernel.

The backup operation has ended.

2015-03-02 00:05:05

Filling reply buffer.

    Have encountered error -24920:

        The database request was canceled and ended with error -903. The backup tool ended with 0 as sum of exit codes.

    Constructed the following reply:

        ERR

        -24920,ERR_BACKUPOP: backup operation was unsuccessful

        The database request was canceled and ended with error -903. The backup tool ended with 0 as sum of exit codes.

Reply buffer filled.

2015-03-02 00:05:05

Cleaning up.

    Removing data transfer pipes.

        Removing data transfer pipe /db2/SID/sapdb/data/files/pipe_mem1 ...

        Done.

    Removed data transfer pipes successfully.

    Copying output of Backint for MaxDB to this file.

    ---------- Begin of output of Backint for MaxDB (/commvault/opt/simpana/SapMaxDbAgent/out)----------

    ---------- End of output of Backint for MaxDB (/commvault/opt/simpana/SapMaxDbAgent/out)----------

    Removed Backint for MaxDB's temporary output file '/commvault/opt/simpana/SapMaxDbAgent/out'.

    Copying error output of Backint for MaxDB to this file.

    ---------- Begin of error output of Backint for MaxDB (/commvault/opt/simpana/SapMaxDbAgent/err)----------

    ---------- End of error output of Backint for MaxDB (/commvault/opt/simpana/SapMaxDbAgent/err)----------

    Removed Backint for MaxDB's temporary error output file '/commvault/opt/simpana/SapMaxDbAgent/err'.

    Removed the Backint for MaxDB input file '/commvault/opt/simpana/SapMaxDbAgent/in'.

Have finished clean up successfully.

*** SAVE/RESTORE request:

SAVE DATA CANCEL

*** SAVE/RESTORE request accepted:

OK

*** SAVE/RESTORE result:

ERR

-24988,ERR_SQL: SQL error

-104,DBM command impossible at this time

*** DBA Action ends:

Timestamp: 20150302000505   State:    Failure

Hi Siva,

As your using Comvault for the backup solution do check below things:-

when you run the backup do the pipe_mem1 get created under below folders, which will confirm that the issue is not at SAP end if the files are getting created.

/db2/SID/sapdb/data/files

Reading the Backint for MaxDB configuration file '/commvault/opt/simpana/SapMaxDbAgent/backint.conf'.

 

 

 

        Found keyword 'BACKINT' with value '/commvault/opt/simpana/SapMaxDbAgent/backint'.

 

 

 

        Found keyword 'INPUT' with value '/commvault/opt/simpana/SapMaxDbAgent/in'.

 

 

   Created temporary file '/commvault/opt/simpana/SapMaxDbAgent/err' as error output for Backint for MaxDB.

 

 

 

   Writing '/db2/SID/sapdb/data/files/pipe_mem1 #PIPE' to the input file.

Also i can see for the logs the backup opration is timing out.:-

Prepare passed successfully.

015-03-02 00:03:47 The database is working on the request.

 

       2015-03-02 00:04:37 The database is working on the request.

 

      2015-03-02 00:05:03 Canceling Utility-task after a timeout of 300 seconds elapsed ...

 

     OK.

 

       2015-03-02 00:05:04 The database has finished work on the request.

 

     Receiving a reply from the database kernel.

 

    Reply from db-kernel:

 

         SQL-Code              :-903

 

     End of reply from db-kernel.

 

The backup operation has ended.

So check with the backup team about the Backup media server where your taking backups to tape is it timing out. Check the backinit file for same.

Also can you let me know if your using dbmcli command lines and version of your MAXdb as there are some limitation for version support by comvault.

And in meantime can you try to reinstall the Comvault agent and install a SAPMaxDB agent as we are using the specific SAPMAxDB agent of comvault in our setup.

Let me know if this helps.

Regards,

Ram

Can anyone please provide the installation guides for SOLMAN 7.1 for MAXDB.

Thanks

Hi

Go to Service.sap.com/instguides >sap components>SAP solution Manager >Release 7.1

Regards

Jayanth

Hello Christophe,

ok, but the hotfix would be for the 'alter table add' problem. To find out, if you are affected, please run the SQL query and let me know the result.

Thorsten

Hi again,

Our main DB is back on 7.8 because we just had far too many -9111 errors with 7.9. However we have 2 other databases now running with 7.9 and they run just fine.

And yes I ran the "null check" query on the 7.9 instance, we had exactly 6356 such columns.

If you have a hotfix for that problem for 7.9, we could of course install it on our 7.9 instance and test everything again (we would migrate our data again and switch again from 7.8 to 7.9).

Christophe

Good morning,

    I'm facing a problem during a MaxDB Database restore.

    There is a database with size of 1 TB (32 Bits) that I need to move it to an other server (64 Bits).

     Actually, I did a restore from the last backup (COMPLETE) and it finished successfully. I don't have INCREMENTAL backups after this last COMPLETE backup and I need to apply all last LOG Backups into the database for consistence.

    My problem is that in the new database, the backup history was lost and it does not recognize the log numbers.

   Do you have any idea how to restore these LOG backups?

Thanks in advance,

Ricardo

Ok, 6356... I have just discussed this and we would like to build once again a special kernel with additional traces for you. This would not be a bug fix, but to identify where exactly the errors are coming from - if you are willing to test this based on MaxDB 7.9.08.28, let me know.

Kind regards,
Thorsten

Hi Thorsten,

        Thank you for you atention.

        I've created the new environment with a Windows 64Bits and MaxDB 64Bits but I'm facing problems with the migration.

        I put a new comment with the subject: "Restore - MaxDB 7.9".

        Could you please take a look ?

Thanks a lot!!!

Ricardo

Yes we could use that special kernel and generate more traces for you, no problem. Just let me know exactly what you expect and how we should run the tests (for example, if we should set some parameters to some special values to make sure that the DB stops when an error is detected).

Thanks,

Christophe

Her is the kernel with additional traces - just replace with your current kernel 7.9.08.28:

https://mdocs.sap.com/mcm/public/v1/open?shr=Bl8zhCTx8eoKDaT2X1fjPklbbz2toL1GCya2f1TWZtw&obj=E_eQykkiYwnCthocJWdc0cGkEZSwXSkRsdW7OQSI3j4

No need to configure anything from your side - no vtrace needed, no further parameters, no slow kernel, just use as it is and if it encounters an error, it should write the traces to the KnlMsgArchive and KnlMsg files.

Thorsten

Hello Thorsten,

Thanks for the kernel, but we unfortunately don't use maxdb in a SAP environment and we don't have access to that SAPCAR utility to uncompress .SAR files. I tried with 7-zip (as advised on some SAP forums) but it also fails. Can you please give us another format?

Thanks,

Christophe

ok, please retry - I have uploaded a 'kernel.bin' file. Just 'kernel' was not accepted, so I have renamed it. You only need to download this and return file name to 'kernel'.

Thorsten

I have to correct one thing:
the additional trace output is written to the kernel trace (even though this trace is not enabled), but not to the KnlMsg/KnlMsgArchive files.

This means for you:
If you notice the error, 'flush' the trace and then convert the binary trace to a text file, e.g.
dbmcli -d ... -u ... trace flush
dbmcli -d ... -u ... trace_prot msakbe

Sorry for the confusion,
Thorsten

PS:
In case the database crashes, the trace is flushed automatically, so you just would need to convert the trace.

Hello All,

I have an SAP ECC 6.0 EHP5 running with SAP MAX-DB on SUSE Linux.

we have allocated 30 GB of RAM to this machine, both data base and SAP app server are running under same host or physical application server.

In the process of performance tuning i have allocated 20 GB of RAM to SAP using em/initial_size_mb and based on this i have adjusted other SAP profiles parameters .

Now i  want to allocate 8 GB of RAM to database , can any one please help me how to allocate this fixed amount of RAM to database MAX DB so that if any query runs on database it responds very fast.

From my understanding SAP MAX-DB uses cache_size to read content from database please correct me if i am wrong.

My current  CacheMemorySize  is  350080 , can i increase this value to higher level so that my max db performance also increases when ever you are running any query on database.

When i open TX  SPRO and expand nodes it takes lots of time to respond, i have changed parameters related to SAP but i have done nothing related to MAX DB. Please help me understand how can i increase performance of maxdb.

On 30 gigs of memory there are only 10 active users , I want this machine to be running on ample speed its a very critical machine for us.

My MAX - DB Release -  " 7.9.08.008 ".

DBSL Patch Level             " 441 "

Please let me know if you need any further logs.

Thanks in advance !!

Regards,

Vardhan.

Hi Vardhan,

I think as long as you followed up SAP note 1346964, then the system general parameters are ok.
If you suspect there is slowness on database, we have to look at the slowness case by case.

Cheers,
James