This website is not affiliated with, sponsored by, or approved by SAP AG.
13 posts • Page 1 of 1
Can anyone who is using VERTEX with SAP tell me whether it's better to have the VERTEX tablespace within the SAP database or in an own database on an other own server?
At this time our VERTEX is using a tablespace within the SAP database (Oracle). As we facing problems with this situation, I'm thinking about to build an own Vertex database but would like to know how other deal with this. Does anyone have any tips with this topic?
We use a dedicated tablespace with own schema (user) in the same database as SAP. We use PSAPnnnn name convension, so that SAPDBA/BRTOOLS can be used to manage everything.
What problems do you face with your setup?
Thank you for the fast answer.
We need to migrate the (SAP) database to uniocde. Unfortunately, Vertex does not support this!
There seems now to be 2 possible solutions:
- Export Vertex tablespace, migrate the database to unicode and import the tablespaces again as non-unicode tablespace within an unicode database (it seems to be possible, even I don't know yet how to do it (?)
- move the Vertex stuff to its own non-unicode database
Both solutions would have their advantage/disadvantage. Therefore I'm interested how other SAP, Vertex customers deal with this
We had the same situation. We did the Unicode conversion. By default R3load ignores the vertex schemd's.
Once your Unicode conversion is done, you have to reinstall Vertex and create a new tablespace with schema in the Unicode version.
Thank you very much for the answer!
Would it be possible to give me any infos how you did this in detail?
I really would appreciate this!
Did you export the Vertex schema before the unicode migration and reimported it lateron again (e.g. with Oracle exp/imp) or did you just build the VERTEX schema new with the scripts from Vertex in the already converted database?
In my case, We did the Unicode conversion with Distribution Monitor so it has only SAP standard schema.
After that, we created a new table space for VERTEX and assigned it as a default tablespace to a new Oracle level user for VERTEX (TAX_USER). The grants are connect, resource
Then with the VERTEX installation documentation, executed a bunch of scripts to create the tables, view and so on. and finally executed the rateins to install the necessary data.
If you need the installation document, send me an email on firstname.lastname@example.org and I can send you the document.
We are upgrading to ECC6 and after that doing the Unicode conversion.
We were also told by vertex support that we will need to move the vertex schema to a separate database.
So how to fix the issue with vertex ? Is it really possible to have the vertex non-unicode tablespace on the same unicode database we have SAP ECC6 system ?
If so which are the right procedures ?
Thanks and best regards,
ask Vertex' makers to give you a procedure.
I have not worked on Vertex and don't know its architecture. But I've done many Unicode Conversions with SAP Distribution Monitor.
If Vertex tablespace is in SAPR3/SAPSR3 schema, the R3load export/import will consider this Vertex tables if the entries are in nametab. Do you see Vertex tables in SE11? It is basically RDDCUCNT (nametab handling) which takes care of these things).
If you are doing combined upgrade and unicode conversion, are you "upgrading the add-on with Vertex CD"?
Another option would be to create its own schema and move the vertex tables (probably in PSAPUSER?) to a new Vertex tablespace (say PSAPVERTEX?). Also, it is possible to move Vertex tablespace in old database to its brand-new database in target Vertex database system. In Oracle (9i upwards), it's called Transportable Tablespaces.
Insofar Non-Unicode Vertex in Unicode database is concerned, if Vertex applications/logic does not require Vertex data to be unicode, you can run non-unicode tablespace in unicode database. In otherwords, the Unicode Converted target database can hold non-unicode tablespace.
You can always experiment this in your crash & burn or test exercises.
Just pointers, not definitive answers. Sorry.
Character sets have a database-wide scope. You cannot create a schema/tablespace with we8dec, say, and the SAP tablespaces in Unicode.
What you can do is have 2 instances per box, one SAP-Unicode and the other one in whatever set you need. However you will need a strong box to support 2 Oracle instances ; the other one will drain your SAP instance if your hardware cannot cope with the extra CPU/IO demands.
In our case vertex has its own schema.
blueteeth told what I would like to know when he said " In otherwords, the Unicode Converted target database can hold non-unicode tablespace."
I think I will follow this approach.
Thanks very much
unicode coexisting with non-unicode in the same instance ? no way.
Check out http://www.sdn.sap.com/irj/sdn/index?ri ... 965a4e5c84 ; currently db2 is the only platform supporting this.
It is still possible.
Let us open the bottle of creativity and imagination.
Go back to year 2006 (or somesuch) there were cases where customers wanted to install Java Add-In to their ECC systems. Java Add-In requires Unicode Capable database but customers did not want to do their Unicode Conversion of SAP ECC (SAPR3/SAPSR3 schema) which had Oracle Charecterset as WE8DEC. Now please refer SAP Note 669902.
The idea is, convert the "entire database charecterset" from WE8DEC to UTF8. Mind you SAPR3/SAPSR3 remains "non-unicode" and fresh install of Java Add-In inside UTF8 database (new java schema) is Unicode.
If non-unicode schema for SAPR3/SAPSR3 can co-exist peacefully with unicode schema of java add-in, I say, it is possible for your Vertex case.
I would proceed like this. First few definitions:
Current System (non-Unicode) - CS
New System - Unicode Converted (using SPUMG etc) - NS
First, do a Unicode R3load export of SAPR3/SAPSR3 schema (R3load will not touch your Vertex schema)
Import R3load in NS (here you have set target database charecterset as UTF8). All okay. SAPR3/SAPSRR3 data converted into Unicode.
Go back to CS (which has charecterset as WE8DEC). Drop SAPR3/SAPSR3 Schema. All you are left with is Vertex schema inside the CS database. Do a charecterset conversion from WE8DEC to UTF8. Please refer the note above. Now your Vertex schema has UTF8 charecterset.
Do a Transportable Tablespace from CS to NS. Viola!! You have moved non-unicode (but UTF8) charecterset Vertex Schema to NS.
Please perform appropriate backups at each step.
13 posts • Page 1 of 1
Users browsing this forum: No registered users and 13 guests