Hi Thorsten,
I've sent you the dump as SYSDDLHISTORY.txt.gz. Please note that it doesn't include the day where we tested 7.9 but there was nothing different than other days.
Thanks,
Simon
↧
Re: Error "-9400 AK Cachedirectory full"
↧
Re: [-9205]: System error: AK Catalog information not found / CONSTRAINT
Hi Bernhard,
thank you for uploading the catalog file. Unfortunately it did not give us any new insights about why the catalog should have become corrupted since the affected table 'RKA_ANTRAGBEARBEITUNG' did not have any unusual constraints set.
We might have found the bug with a database restart followed by a 'default' kernel trace plus 'select' option enabled while the catalog was still corrupt, but now it is too late for that since you had that table already dropped and rebuild.
We have added this incident to our bug tracking tool per PTS1254412, although at this point we most likely do not have enough information to fix it:
"Error -9205 "System error: AK Catalog information not found: 000000000003F5F5000A000F" at
SELECT CONSTRAINTNAME, DEFINITION, CONSTRAINTTYPE FROM DOMAIN.CONSTRAINTS WHERE SCHEMANAME = <schemaname> AND TABLENAME = <tablename>
Check catalog does not show any problem.
Problem is probably a lost catalog record for some constraint information (see cak_eviewdesc in a44constraint_into_moveobj)."
Regards,
Thorsten
↧
↧
Identity columns
Hello,
a short questions, do all SapDB/MaxDB Versions support identity columns (I mean default serial)?
Thanks!
Tiberius
PS: sorry, my first post was accidentally a document, not a question...
↧
Re: Error "-9400 AK Cachedirectory full"
Hi Thorsten,
Will there be a new 7.8 release where at least our former bug is fixed? It would already help a bit.
Regards,
Simon
↧
Re: Error "-9400 AK Cachedirectory full"
Hi Simon,
since the 'alter table add column' optimization is a important feature/requirement for MaxDB 7.9, we would be very interested in locating and eliminating that bug, but we might need your help.
You had mentioned that at crash day around 9:06 an alter table add column was performed. Can you let me know which table was involved? This would help going through the sysddlhistory, although of course we do not know if that 'alter table' command was resposible for the crash or maybe another older one.
In the next days, we will be going through our code and check for possible errors with that feature and if we do not find something, we will have to use another approach.
It would be really helpful, if you could trigger that bug in your test environment, but if that is not happening, we will try to find another solution...
Regards,
Thorsten
↧
↧
SAP MaxDB storage requirement
Hello,
Does anyone know where could I get the disk space/file system design requirements for initial installation of SAP ERP 6.0 with MaxDB 7.9 on Solaris SPARC 10?
Thank You
Edy
↧
Re: SAP MaxDB storage requirement
Hi Edy,
Normally we can find such kind of information from installation guide. Are you able get what you want from the installation guide?
Best regards,
James
↧
Re: Error "-9400 AK Cachedirectory full"
Hi Thorsten,
I'm afraid the sysddlhistory will be of no use for you because the day of the crashes with the 7.9 version is not in there. The history is only from the working 7.8 version and the 7.9 instance doesn't exist anymore 
Regards,
Simon
↧
Re: Error "-9400 AK Cachedirectory full"
Hi Simon,
yes, I know. But I thought that the "alter table / drop table / add column..." statements were a regular feature of your application (which seems a bit unusual to frequently add columns and then later delete them, but I thought that was how your application was designed...).
In that case it would make sense to have the table table name which crashed the database of 7.9, because very similar statements should also be in the sysddhistory for 7.8.
But maybe my assumptions were wrong...
Regards,
Thorsten
↧
↧
Re: Error "-9400 AK Cachedirectory full"
Hi Thorsten,
I know there are some create/drop table daily but not with alter table from what I know. And I'm sure the alter table.. on that day was a unique command done by one of the developers. So, nothing related or a repeating pattern would be found in the history.
Regards,
Simon
↧
Re: Error "-9400 AK Cachedirectory full"
Hi Thorsten,
As one of the developers of this system, I can give some more information.
First, as an introduction:We don't have software releases in the classical way: We usually have a new version every day. Sometimes, we have two versions running in parallel if new features are needed urgently. We neither have a test database, meaning, we work and change on the live database!
We have two different ways to change the database scheme:
What Simon mentioned, we add temporary tables, insert data, do something with the data, and in the end, we drop those tables again. Those tables are never changed, just created, used and deleted again.
We as developers (currently 7) do changes. We only do some changes during the day:
- Add tables, indexes, foreign keys, constraints and triggers
- Change columns (defaults, nullable...)
- Change constraints and triggers
- Drop indexes, foreign keys, constraints and triggers
- What we rarely and only under certain circumstances do:
- Drop columns
- column is brand new and was not yet used (mistake during creation usually)
- Table will not be used for the day until we have the new software version. Our framework can't handle deleted columns at runtime
- Add columns to table where columns have been previously deleted and the datatype allows reuse of that deleted space, again, our framework has problem handling that case.
Deleting columns is done in the evening when no users are present. We restart our system after that but usually not the database server.
Regards,
Daniela
↧
Re: Error "-9400 AK Cachedirectory full"
Hello Daniela and Simon,
thank you for the detailed reply.
While we are trying to trigger this bug with in house testing, these questions came up:
Do you know if the 'alter table column add' command was executed with or without the 'default' option in 7.9?
Do you know or suspect on which table the alter command was issued which later crashed the database?
Regards,
Thorsten
↧
Re: Error "-9400 AK Cachedirectory full"
Hi Thorsten
As we had to replay that change on the 7.8 database, we know what it was:
ALTER TABLE BUILDING_UNIT_CONTRACT ADD EXTEND_CONTRACT_DATE DATE
According to our auditing, there was no update or insert to that table after the 16 of September and there is currently no record with a non null value for this column. Our auditing for the 17 is not 100% reliable because of the migration back to 7.8 so it would be possible that it has been set and reverted back to null at this day.
Regards
Daniela
↧
↧
Re: [-9205]: System error: AK Catalog information not found / CONSTRAINT
Hello Thorsten,
that`s no problem. If it helps I can set up a local instance and import a backup.
Regards,
Bernhard
↧
Re: [-9205]: System error: AK Catalog information not found / CONSTRAINT
Hello Bernhard,
yes, that would help indeed.
Here is what you would need to to:
1. Restart the database (to ensure that the command is not already cached)
2. Activate the kernel trace with options 'DEFAULT' and 'SELECT'
-> e.g. 'dbmcli ... trace_on TRACE_DEFAULT TRACE_SELECT'
3. Trigger the error
4. Flush the trace (so that the trace buffer gets written from memory to a file)
-> 'dbmcli ... trace_flush'
5. convert the flushed binary trace file to text
-> 'dbmcli ... trace_prot akbmnx'
6. Trace will stay active until disabled (even if database was restarted), so do not forget to disable
-> 'dbmcli ... trace_off all'
Regards,
Thorsten
PS:
the kernel trace can also be activated via database studio GUI, if you prefer the graphical frontend
PPS:
If you are unsure about the current trace state, use 'trace_show' to display a trace status list
↧
Blank SMIGR_CREATE_DDL, ORA to MAXDB migration
Dear Experts,
I'm in the mids of test to perform Database migration from Oracle 11.2.0.4 to MaxDB 7.9.
I execute the report SMIGR_CREATE_DDL on source system (Oracle) and select MaxDB as a target.
The log say, "DDL statements generated successfully"
Why the output file SQLFiles.LST give the output as below:
root@ecc#more SQLFiles.LST
#
# MSSQL : LIST OF .SQL FILES OF NATIVE SQL EXPORT GENERATED AT 20151105190144
#
It show that the SQLFiles.LST not showing any .SQL files.
Why it happen? Am I missing something?
Kindly aid me to solve this issue.
Thank You
Edy
↧
ERROR in initialization (can't get SVERS-version) while installingECC6 Ehp6 MAX DB
Hi,
We are trying to install ECC6 EHP6 on MAX DB. during DB activation phase this installation stopped due to below error.
tail dipgntab.log
ERROR in initialization (can't get SVERS-version)
ERROR in initialization (can't get SVERS-version)
Please suggest.
↧
↧
MaxDB and CCMS
Dear all,
I need to connect my MAXDB to SolMan CCMS according this helpful scn treed http://scn.sap.com/docs/DOC-58045
All actions ends successful, but at the step when i need "Create xuser with keys c, c_J2EE and <SID>. ( SID of Maxdb instance)." i cant understand, what and how i need to do.
From root and daaadm i start this command:
/sapdb/programs/bin/xuser -u control,<control pass> -d <DB SID> -n <my host> -U <my key>
But it is not help. please, anybody guide me.
↧
Re: Blank SMIGR_CREATE_DDL, ORA to MAXDB migration
Hello Edy,
I think you should create a SAP ticket for this as we will likely need to logon to that server (probably best to start with BC-INS-MIG).
It seems at least odd that the error output has a MSSQL tag (MS SQL Server) when you intend to migrate from Oracle to MaxDB...
Regards,
Thorsten
↧
Re: Blank SMIGR_CREATE_DDL, ORA to MAXDB migration
Hello Thorsten,
Thank you for your suggestion. I have been created a SAP Ticket for this issue.
Regards,
Edy
↧