Yes, it turns out we were indeed missing a Content Delivery hotfix. We installed the latest cumulative CD hotfix (CD_18.104.22.16857), which solved our issue. The specific hotfix that originally caught our attention was CD_22.214.171.12400, as its problem description was exactly the issue we were seeing.
For anyone else stuck with this, here's the solution.
Oracle 12c introduces multitenancy. With this architecture the Tridion Content Delivery database must be set up in the pluggable database rather than the container database that is the default when you first connect via sqlplus.
To switch to the pluggable database you will need to log in "sys as sysdba" ...
You can use Oracle's JDBC thin driver syntax like so:
Doesn't that same documentation explain what these scripts do? (It does, AFAIK)
Only AnalyzeStats.sql and RebuildIndexes.sql are intended for regular maintenance; the other scripts are analytical -- to get insight in the state of the DB and whether maintenance is needed.
I've done it once for a customer, it was a horrible job to do since the sequences didn't migrate well with the data migration assistant from Oracle (but that might have changed as it was a long time ago). We fixed that by setting them all manually, but it took quite a while before everything was running without any errors.
It isn't a supported process for ...
Yes, it's possible, I've done it before, but don't expect to get SDL support afterwards. I've migrated Oracle to MS SQL, but steps are still the same:
Create a database on Oracle. It should be of same version as MS SQL. This will give you correct stored procedures
Migrate data from all tables. There are plenty tools to do the job for you. Most of the tables ...
I've found a very informative answer by Nuno on this subject. It seems that Oracle can not be used with cloud service providers such as RDS and Azure due to this specific problem with limitations on the master user account.
If you are wanting to go down the path of setting up their own Oracle 12c database on Amazon EC2 I have written a three part guide on ...
I think that that Stored Procedure is used when a Directory Service user ("LDAP user" if you wish) logs in. This means it is a very commonly used Stored Procedure and thus it is very unlikely a general product defect.
Much more likely is that the number of open cursors is exceeded by a suboptimal query execution plan in the database. These plans are ...
It appears from the following error message (at the end of your first line of logging):
Oracle.DataAccess.Client.OracleException: ORA-00600: internal error code, arguments: [kdsgrp1], , , , , , , , , , , 
... that this may be an Oracle issue (possibly a corrupt database file):
Sounds like a 32 x 64 bit Oracle client issue. Some of the lists retrieved by the CME use the CoreService (x64) while opening individual items (not all, but most) still use COM.
The TCM54 in the URL you mention means this call is going through the COM/TDSE bridge, which indirectly means it's using the 32 bit client.
I would try re-installing the Oracle ...
The problems you may spot are related to database and not to Tridion per se. Even more you might have problems migrating between the databases of the same type. For example: you may have different character set, this might result in some exotic characters being displayed differently or maximum name of an item be slightly shorter on one of the databases if ...
I would not expect any issue because the Content Porter calls the Tridion Core Service API which is an abstract layer on top of the database.
However I did not try it myself so will let others detail their experiences.
Is this for a migration or do you have disparate systems in your DTAP setup? I would not recommend the latter.
Have you tried serviceName instead of databaseName?
SDL Tridion online manual has an instruction for the property when using service name in Oracle.
That instruction can be found in "Configuring content storage" section (login required).
Are you using API queries, or are you querying the database directly? Do you have some examples?
Have you checked with your Oracle DBA as well for possible solutions?
Here is another post which can give you a sense of several possible workarounds from a database standpoint:
This is an Oracle specific error (not related to Tridion) and it occurs because of the scope/container where you are trying to create the user in the Oracle DB. You should try option mentioned in the below link which should resolve the issue: https://dba.stackexchange.com/questions/60806/oracle-12c-create-user
Couple of other links describing the issue and ...
Note that Content Porter is not intended for database migration purposes.
It doesn't port all data in the system, you loose version histories and you will hit size limitations if you try to export your entire CM system.
If you only want to port a limited number of items (and don't care about the functional limitations), there should be no issues with ...
Got it working. I just navigated into the FipsAlgorithmPolicy folder and changed the "Enabled" DWORD from 1 to 0 and the install worked just fine from HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
Looks like Oracle connectivity issues.
Try to verify following to fix that issue.
Ensure your Microservice server installed oracle client and the tnsnames.ora file configured and file that contains network service names mapped to connect descriptors for the local naming method, or net service names mapped to listener protocol addresses. A net service name ...
bump up the 'open_cursor' to 2000 (from 400) seem to have helped.
ALTER SYSTEM SET OPEN_CURSORS=2000 SID='*' SCOPE=BOTH;
Of course, the 2000 value is varied from one system to another...you just have to do trial and error to see what value is best.
Are you getting this error only when you try to create an item using Core service, but you have no issues with create a item inside CME manually?
If so, we may be logging as different users with different permission rights for core service and CME Web.
If the error occurs in both in CME and core service, it could be that we installed a hotfix, but forget ...
I would try to isolate this to being a "plain old ORACLE" problem if possible. Try testing the connection with TNSPING etc., as described in the ORACLE Documentation.
If you can reproduce your problem with these tools, then this is something your local ORACLE specialist can focus on without having to worry about Tridion.
BTW It's very easy to miss ...
After working with DBA to have the Tridion CM schema/db on an Active/Passive scenario within a cluster per SDL Model. I was able to successfully promote content via Content Porter
I am not sure if this is related, but before the switch to A/P we also noticed that the Archive log generation and SMON locking issue below were resolved per @JonathanWilliams ...
In addition to what others has suggested, please also follow the Installation Manual for SDL Tridion as you may need to apply some additional patch while you shift to Oracle.
Regarding where all you need to change the type of DB and the DB instance, you may choose the SDL Content Manager Config MMC, but once you do changes in any value, do not forget to ...