Hi Steffen,
I understand. Great and thank you very much.
Regards,
Werner
↧
Re: MaxDB 7.9 error when importing data from MaxDB 7.6
↧
Lock request timeout (SQL-HY000) after one week
Hi all,
we're running MaxDB 7.8.02.37 in an non SAP environment.
Currently we are in the situation that we have one lock request timeout on one specific application table.
We have changed our application several times regarding the locking/unlocking mechanism, but unfortunately it seems we havn't found the cause.
But there is one interesting issue, which we don't understand:
After each change we're restarting the database and then for around one week everything works fine and no lock request timeouts occur.
After one week (between 6 and 8 days) the lock request time out for this one table starts again.
Our application runs a 24/7 call centre application, so the behaviour of the users didn't change after a week.
Does any one have an idea about that?
Thank and best regards
Hannes
↧
↧
Re: Upgrade 7.9.07 BUILD 014-123-244-287 to 7.9.08.22 not possible
Something seems wrong:
dbmcli on pagsapup1 : UP1>sql_execute select * from users
ERR
-24988,ERR_SQL: SQL error
-4004,Unknown table name or unknown schema:USERS
---
dbmcli on pagsapup1 : UP1>sql_execute select * from DOMAIN.USERS
ERR
-24988,ERR_SQL: SQL error
-4004,Unknown table name or unknown schema:USERS
↧
Log of password changes
Hello!
We are running SAP ERP system on MaxDB 7.8.02.034.
For some days we are detecting that all the password of database users such as control, superdba and sap<sid> have been changed.
Questions:
1) Is the any possibilities to see when and by whom these changes were made?
2) What is the easiest way to turn back all the password changes?
Many thanks!
↧
Re: Upgrade 7.9.07 BUILD 014-123-244-287 to 7.9.08.22 not possible
Hi Daniel,
Connect with user control and check db_state.
Post this check whether you can execute the sql command.
Regards,
Deepak Kori
↧
↧
Schema user passwords are changed after import by loader
Hello,
after migration from MaxDB7.6 to MaxDB7.9 via loader, the schema user passwords are not valid any more.
How can we avoid that passwords are changed or is there a easy way to set them to the original value ?
Thank you for any help.
Regards,
Werner
↧
Re: Schema user passwords are changed after import by loader
Hi Werner,
Did you follow the guidelines as specified in SAP Note 962019 - System copy of an SAP MaxDB Content Server database
Regards,
Deepak Kori
↧
Re: No user connect after upgrading to 7.7
Hello,
may I ask, how the problem has been solved at the end. Was it the truth that only the first nine characters are been used for password verification ?
Regards,
Werner
↧
Re: Schema user passwords are changed after import by loader
Hello Deepak,
as we had to migrate from version 7.6 to 7.9 we could not follow these steps. Also change from Ascci to Unicode has to be done. So we used the loader utility for migration.
In the catalog file I can see, that all passwords has been set to "initial".
Is there a way to copy the password string from the source database to the target database ?
Is there a way to grant the standard users only the privilege to change their own password, like grant alter user to <username> ?
So it would be possible that users can change their passwords.
THank you in advance.
Best regards,
Werner
↧
↧
Re: Client connection to MaxDB7.9 is very slow
Hi Thorsten,
the x_ping shows the following:
[sdb@defrap1060 pgm]$ x_ping -n 10.171.230.170 -d adb1
Pinging adb1 on 10.171.230.170 with 512 bytes of data over a maximum of 10 hops.
Hop Server
0 XServer
1 ADB1
ADB1: reply time=395us
ADB1: reply time=363us
ADB1: reply time=348us
ADB1: reply time=389us
ADB1: reply time=357us
ADB1: 'UNKNOWN'
Approximate round trip times:
Minimum = 348us, Maximum = 395us, Average = 370us
But from the more faster database it took 18ms, as shown below. But there I got immediately feedback, whereas for the first one it took about 45 seconds until I got feedback.
[sdb@defrap1060 pgm]$ x_ping -n 10.253.1.16 -d adb1
Pinging adb1 on akde6069.de.kaercher.com with 512 bytes of data over a maximum of 10 hops.
Hop Server
0 XServer
1 ADB1
ADB1: reply time=18 ms
ADB1: reply time=18 ms
ADB1: reply time=17 ms
ADB1: reply time=18 ms
ADB1: reply time=18 ms
ADB1: 'KERNEL 7.6.03 BUILD 015-123-173-107'
Approximate round trip times:
Minimum = 17ms, Maximum = 18ms, Average = 18ms
So I guess it is more a initial thing at a lower network level.
KG,
Werner
↧
Re: Client connection to MaxDB7.9 is very slow
Hi Werner,
if I understand you correct, then the 'x_ping' to 10.171.230.170 hangs for about 45 seconds and only then delivers the result?
If so, it may very well be a problem with the reverse DNS lookup in your network to that server 10.171.230.170. The involved MaxDB 'x_server' definitely uses reverse DNS lookup (which means that the given IP address is used to look up the server name).
To verify if this is indeed the problem cause you could try to start the 'x_server' on the database server 7.9 with the following options:
1. go to database server 7.9 (10.171.230.170)
2. execute 'x_server stop'
3. Start a new x_server without DNS lookup using 'serv directly (which normally gets called through x_server) -> 'serv -F'
Hope this still works via the 'serv -F' command; Then, just return to the client server and retry the 'x_ping' / 'sqlcli' against the 7.9 database...
Thorsten
↧
Upgrade from 7.3 to 7.9
Guys,
I have to upgrade a 32 bit 7.3 instance on 2003 to 64 bit 7.9 (for Content Server usage) - there is no 7.4 MaxDB that I can see on sapnet. Can anyone suggest an upgrade strategy? Does anyone have any experience of such a huge jump?
↧
Re: Upgrade 7.9.07 BUILD 014-123-244-287 to 7.9.08.22 not possible
Problem is resolved by http://service.sap.com/sap/support/notes/1882932 - the password was destroyed during the upgrade.
↧
↧
Re: Upgrade from 7.3 to 7.9
Hi Neil,
As DB is at 7.3 you need to first upgrade it to 7.6 atleast and then upgrade to 7.9.
Follow information in SAP note below to plan the upgrade
962019 - System Copy of SAP MaxDB Content Server Database
Regards,
Deepak Kori
↧
Re: Upgrade from 7.3 to 7.9
thanks Deepak!! - do I take it from that note then that we won't be able to carry out a backup / restore of the 7.3 DB - will we have to use the re-location of documents approach?
↧
Re: Upgrade from 7.3 to 7.9
Could we get round the relocation of documents by upgrading the Content Server 6.3 on the Source System to 6.4, before carrying out the homogeneous system copy?
↧
MaxDB cache pinning
I've done a bit of research on MaxDB cache pinning but I am still not clear on a few items. I'm hoping the community can offer some advice.
1. What is the best way to determine which tables to pin? Some of the documentation leads me to believe you should use tables with high reads and low writes, but other documentation mentions high access tables. Is the term "access" referring to a combination of read and writes?
2. Is there a way to determine if a table is currently in the regular cache area versus the pin cache area? If it is already in the regular cache most of the time, it might not be valuable to pin it.
3. How do you determine if pinning was successful? Can you do some before and after testing to make sure the pinning is helpful?
If you can offer any other advice or tips and tricks that would be very helpful.
Regards,
Steve
↧
↧
MaxDB 7.3 Restore issue
Hi,
I'm trying to restore a 7.3 MaxDB across to a test server so that I can upgrade the Content Server. I'm getting the following error :
-24988 sql erro [util_execute INIT CONFIG]; -902,Message not available,wrong path specified.
Any help here would be greatly appreciated. I'm new to MaxDB and the there are very little resources out there for 7.3
Regards
Neil
↧
Re: MaxDB cache pinning
Hi Steve,
first let me say that 'cache pinning' is not used in the usual SAP MaxDB installations. This feature has primarily been introduced for MaxDB running as liveCache installation where we wanted to ensure that some vital SQL tables would always stay in the cache.
This said, there is not much guidance I can offer for normal MaxDB installations as to which tables to pin and what size to reserve -it really depends on the individual scenario.
If you want to use table pinning, I would strongly recommend to identify tables you think would most benefit from being permanently in the data cache. This would likely be small tables (so that the pinning area can be kept small) which are frequently accessed or which you have experienced long run times you could not optimize with a index or by rewriting the SQL.
For enabling table pinning you need to first reserve space in the data cache by setting the parameter 'DataCachePinAreaThreshold'. All tables to be pinned must have the 'CACHE' attribute set (create/alter table ... cache/nocache).
If you enable the MaxDB Database Analyzer (always strongly recommended!), you can look at the data in the DBAN_CACHES.csv file to determine the table pinning effectiveness - the last 4 columns are of interest here:
1. PinPag_Acc (accesses to pinned pages)
2. PinPage_Succ (successful accesses to pinned pages)
3. PinPage_Fails (failed accesses to pinned pages)
4. PinPage_Hit (hitrate to pinned pages).
Important is that your pinned table should completely fit into the pin area.
However, tracking the effectivness becomes complicated if you pin several tables as there is no way to record the hitrate for each table individually.
Hope this helps,
Thorsten
↧
Re: MaxDB 7.3 Restore issue
Hi,
'wrong path specified' basically means that the file could not be located at the given path. If I remember correctly, the GUI is a bit misleading here as under path you need to include the path+filename. You might also want to look in the database log files like 'knldiag' for further info.
Thorsten
↧