on 11-08-2012 10:41 AM
Hi,
I think I found a bug on the jdbc driver (or on the db) shipped with 7.8.02.21.
When EnableVariableOutput is YES, the following query returns an incorrect number of rows. Using an older JDBC driver, or setting the parameter to OFF returns the correct result.
select spedizione0_.ID as col_0_0_ from ECF3.SPEDIZIONE spedizione0_ left outer join ECF3.FATTURA fattura1_ on spedizione0_.ID_FATTURA=fattura1_.ID left outer join ECF3.FATTURA_RIGHE righe2_ on fattura1_.ID=righe2_.ID_FATTURA where spedizione0_.ID_CANALE=9 and spedizione0_.ID_PUNTOPARTENZA=1 and spedizione0_.ID_CORRIERE=1 and spedizione0_.DATA>='2012-04-01' and spedizione0_.DATA<='2012-04-30' group by spedizione0_.ID order by spedizione0_.DATA
removing
order by spedizione0_.DATA
always works whatever version of jdbc driver or setting of EnableVariableOutput parameter
Hi Andrea,
could you please upgrade your database kernel to 7.8.02.31 and check this issue again.
I found a fix which sounds it could fix your problem as well.
Regards, Christiane
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Andrea,
could you pelase provide the link which you are using for download the version.
The fix I'M thinking about is available in 7.8.02.28 as well.
So an upgrade to Build 28 should help as well.
Please tell me your problem during the upgrade to the newest build.
Which tool do you use - SBINST or SDBUPD?
Please attach the log file.
Regards, Christiane
I usually download updates from this page http://www.sdn.sap.com/irj/scn/maxdb-downloads.
Is there another place where I can download a newer version ?
I'd like to retry to update with the latest update if possibile.
Thanks
Following the update guide here http://maxdb.sap.com/doc/7_8/44/d962dbd06f3ee2e10000000a114a6b/frameset.htm.
I haven't understand if I must stop the databases before starting SDBINST. Can you please clarify ?
Thanks
Yes, you have the database must be in state 'offline' before the upgrade. If further processes like 'x_server' or 'dbmserver' need to be stopped, the installer will let you know in its log file.
If possible, I would recommend using the 'sdbupg' upgrade program (unless you want to keep your old database software on the server).
Thorsten
The update guide says:
"Use the SDBINST program for an upgrade if several databases use the software of
the same installation path".
But even that is not a problem, if you want to upgrade all your database instances at once, so you can still use sdbupg, if you want to have all databases upgraded to 7.8.02.28.
If you want, you can check if your instances share the same installation path with the help of 'xinstinfo'. Just type 'xinstinfo <dbname>' for all your instances and check the output for the 'InstallationPath'.
I would really recommend using sdbupd...
Thorsten
I get an error. Can you please help ?
SAP MaxDB Installation Manager - Database Upgrade 7.8.02.28
***********************************************************
Upgrade Database:
0: ECF3 "/opt/sdb/MaxDB" 7.8.02.21
1: ECF3REPO "/opt/sdb/MaxDB" 7.8.02.21
2: GECOMBI "/opt/sdb/MaxDB" 7.8.02.21
3: JMS "/opt/sdb/MaxDB" 7.8.02.21
4: WARPPERM "/opt/sdb/MaxDB" 7.8.02.21
5: None (Abort upgrade)
please enter database id: 0
ERR: Upgrade failed
ERR: installation path must not equal global program path
#xinstinfo ECF3
IndepData : /home/sdb/data
IndepPrograms : /opt/sdb/MaxDB
InstallationPath : /opt/sdb/MaxDB
Kernelversion : KERNEL 7.8.02 BUILD 021-121-242-175
Rundirectory : /home/sdb/data/wrk/ECF3
Ok, so you have installed your MaxDB version 'dependent' part (the 'Installation Path' is part of that) in the 'independent' path (where 'IndepData' and 'IndepPrograms' are located).
I would advise against that, because it prevents you from using sdbupg and you cannot use different software versions for your databases.
If you want to keep it as it is, then you should indeed follow the instructions you had posted above regarding the 'sdbinst' and then doing the follow up activities manually as outlined there.
What I would suggest is to separate your database instances, so that each database gets its own installation path. Before you start, trigger a database backup, so that you can restore, if anything does not work out as expected. The idea is to use the tool 'dbmrelocate' (available since MaxDB 7.8.01.14) to move the database you want to upgrade (or possibly all available instances) in a separate directory. Please have a look at the following example in http://wiki.sdn.sap.com/wiki/x/p4PJC, if you want to try this. Of course, the affected databases must be offline...
Thorsten
Thank you for the continued support.
I think I used the default for the various folders, however, I tried to use the suggested command to move the database to a 'version specific' folder I just created but I get another error. Can you please help ?
#./MaxDB/pgm/dbmrelocate -d WARPPERM -target /opt/sdb/7.8.2.28 -v
dbmrelocate: Checking database 'WARPPERM'...
dbmrelocate: Determine source path for database 'WARPPERM'...
dbmrelocate: Checking source path '/home/sdb/data'...
dbmrelocate: File '/home/sdb/data/config/WARPPERM.upc' found!
dbmrelocate: Checking target installation '/opt/sdb/7.8.2.28'...
dbmrelocate: Preparing move of 'WARPPERM'...
dbmrelocate: Checking versions ...
dbmrelocate:
Moving database 'WARPPERM'
from source installation '/opt/sdb/MaxDB'
and source data path '/home/sdb/data'
to target installation '/opt/sdb/7.8.2.28'
and target data path '/home/sdb/data...
dbmrelocate:
Are you sure? (y/N)
y
dbmrelocate: Unregister database 'WARPPERM'...
dbmrelocate: Register database 'WARPPERM' in '/opt/sdb/7.8.2.28'...
dbmrelocate: Error error register database 'WARPPERM' in '/opt/sdb/7.8.2.28'!
dbmrelocate: Error : no kernel executable found
Is the problem related to the Rundirectory folder that is not a subfolder of IndepData ? If yes, what can I do to update ?
This is strange - the error says that the MaxDB 'kernel' was not found in '/opt/sdb/7.8.2.28' (and then .../pgm subdirectory) and therefore the registration failed.
Can you post the output of 'sdbregview -l' and 'xinstinfo WARPPERM'?
If this does not help, can I reach that server via SAP telnet ssh connection? I know that the affected MaxDB instances do not seem to be SAP databases, but if you have an SAP installation, I could connect to that server and then rlogin further to reach that server.
Thorsten
But 7.8.2.28 is a new folder I just created... So it's normal it's empty (maybe I haven't understand your suggestion to fix the problem and use SDBUPD).
Here's the output :
# ./programs/bin/sdbregview -l
Installation: Global /opt/sdb/MaxDB
Global Listener 7.8.02.21 valid 64 bit
Installation Compatibility 7.8.02.21 valid 64 bit
Installer 7.8.02.21 valid
Installation: Legacy /opt/sdb/MaxDB
DB Analyzer /opt/sdb/programs 7.7.07.16 valid 64 bit
Database Kernel /opt/sdb/7706 7.7.07.16 valid 64 bit
JDBC /opt/sdb/programs 7.6.06.05 valid
Loader /opt/sdb/programs 7.7.07.16 valid 64 bit
Messages /opt/sdb/programs MSG 0.8507 valid
ODBC /opt/sdb/programs 7.7.07.16 valid 64 bit
Redist Python /opt/sdb/programs 7.7.07.16 valid 64 bit
SQLDBC /opt/sdb/programs 7.7.07.16 valid 64 bit
Synchronization Manager /opt/sdb/programs 7.7.06.09 valid
WebDAV Servlet /opt/sdb/programs 7.7.07.16 valid
WebSQL /opt/sdb/programs 7.7.07.16 valid
Installation: MaxDB /opt/sdb/MaxDB
Base 7.8.02.21 valid 64 bit
DB Analyzer 7.8.02.21 valid 64 bit
Database Kernel 7.8.02.21 valid 64 bit
JDBC 7.6.06.07 valid
Loader 7.8.02.21 valid 64 bit
Messages MSG 0.10269 valid
ODBC 7.8.02.21 valid 64 bit
Redist Python 7.8.02.21 valid 64 bit
SQLDBC 7.8.02.21 valid 64 bit
SQLDBC 77 7.8.02.21 valid 64 bit
Server Utilities 7.8.02.21 valid 64 bit
# xinstinfo WARPPERM
IndepData : /home/sdb/data
IndepPrograms : /opt/sdb/MaxDB
InstallationPath : /opt/sdb/MaxDB
Kernelversion : KERNEL 7.8.02 BUILD 021-121-242-175
Rundirectory : /home/sdb/data/wrk/WARPPERM
I have no SAP installation, sorry.
I also tried with another empty folder, because I think that the first folder was used in the past to install the db with SDBINST and later removed.
The error is a little different.
What I haven't understand is if I should use as a target an empty folder (where some files will be moved by the relocate command) or if it must contain a MaxDB installation.
Can you please clarify ? Thank you very much.
# dbmrelocate -d WARPPERM -target /opt/sdb/db78228 -v
dbmrelocate: Checking database 'WARPPERM'...
dbmrelocate: Determine source path for database 'WARPPERM'...
dbmrelocate: Checking source path '/home/sdb/data'...
dbmrelocate: File '/home/sdb/data/config/WARPPERM.upc' found!
dbmrelocate: Checking target installation '/opt/sdb/db78228'...
dbmrelocate: Error checking target installation '/opt/sdb/db78228'!
dbmrelocate: Error : could not read from registry, error message:
There is no error after the colon.
I have just read through my answers above and I think I have been misleading you - sorry for the confusion, its been some time that I had used 'dbmrelocate' myself...
The purpose of 'dbmrelocate' is to move databases from one software installation path to another software installation path. This works fine, but you must have exactly the same database software installed in the new path - so, yes, the target folder must contain a MaxDB software installation.
The problem with your upgrade was that the 'Indep'Programs' path is the same as the 'InstallationPath' for all your databases. I would still recommend to change this.
Here is my suggestion:
1. Use sdbinst of version 7.8.02.21 to install the database software in for example '/opt/sdb/78'. It is important that you use a version that matches the databases you want to move (because dbmrelocate cannot upgrade...). It is perfectly fine that all your instances of 7.8 are sharing the same installation path, so no need to separate them (as I might have had incorrectly suggested, I think). This installation path will remain the same even if the database software is upgraded, so you probably should not call it something like '...78021', because soon you will have software of 7.8.02.28 installed, therefore better not use database version numbers...
2. When you are done with sdbinst, use 'sdbregview' to verify that you have a new installation path available.
3. Now start 'dbmrelocate' to move the existing databases of version 7.8.02.21 to the new installation path (the '-target' switch must point to the sdbregview install directory output). If you want to test only (without moving anything), use the '-simulate' switch first and then repeat without simulate, if the result looks good.
4. Once the 7.8 databases are relocated and separated from the 'IndepPrograms' path, you should be able to upgrade them easily with 'sdbupg' from now on.
Thorsten
User | Count |
---|---|
76 | |
9 | |
8 | |
7 | |
6 | |
5 | |
5 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.