I'm trying to start using flyway v2.3 on an existing Oracle 11g schema that does not contain the schema_history table
In my flyway.properties i've set the flyway.user to the schema owner and i've set the flyway.schemas property to the same value
When running init from the command line I expected flyway to only create the schema_history table but it fails with this message:
$ ./flyway.cmd init
Flyway (Command-line Tool) v.2.3
Creating schema "myschema" ...
ERROR: Unable to create schema "myschema"
ERROR: Caused by: java.sql.SQLSyntaxErrorException: ORA-01031: insufficient privileges
Why is flyway attempting to create the schema? I only want it to create the schema_history table in the schema I configured
The command is correct. Please note that flyway.schemas is case-sensitive and automatically filled with the default schema of the user if left empty.
I suspect the value you put in flyway.schemas is in the wrong case. Just leave it empty and you should be ok.
So you have to be sure you want to work on schema which belongs to user name with which you login. If you want to work in different schema you have to specify inside flyway.properties.
I've just had the same problem in Flyway Maven plugin 3.1.
I turned out that I have created my user with lowercase name
CREATE USER myuser ...
And I gave Flyway
flyway.user=myuser
But while connecting my user's name was cast to uppercase, so Flyway reported that user of name MYUSER did not exist.
Solution: Create and use Oracle DB user with uppercase name.
Related
Using the OrientDB Console.bat for manage oreient-db databases shows some inconsistent behaviour.
1) I created a new db named demox using the below command :
orientdb> create database plocal:../databases/demox root root plocal graph
Creating database [plocal:../databases/demox] using the storage type [plocal]...
2018-04-12 19:10:26:775 INFO Storage 'plocal:../databases/demox' is
created under OrientDB distribution : 2.2.33 (build 77584cd6827f647cf4aa231cf27bd6f10bc04e2c, branch 2.2.x)
Database created successfully.
Current database is: plocal:../databases/demox
2) Next i try to run the drop database command and it errors out saying invalid username or password
orientdb {db=demox}> drop database plocal:../databases/demox root root
Error: com.orientechnologies.orient.core.exception.OSecurityAccessException: User or password not valid for database: 'demox'
DB name="demox"
orientdb {db=demox}>
However If you see the credentials used in step1 and step2 both are same.
I am not sure where the issue is , or am i missing something in the drop database command.
Why would the console error out even when i am using the same credentials for drop-database command as the one i have used while creating the database
use the same command but with the credentials of admin (user:admin pass:admin)
drop database plocal:../databases/demox admin admin
If you have any more questions about this feel free to ask.
We want to be able to pin all sql executions to a particular schema_version table in schema A. We need this so that we can run sqls as a sysdba and flyway always references A.schema_version to validate checksums and update result of SQL runs. We tried by adding the following settings:
flyway.schemas=A
flyway.table=schema_version
However we find that if we run info as user B then flyway is not able to show it can read A.schema_version. What are we missing?
Found out the solution. Schemas is case sensitive as specified in the flyway docs. We needed to reference flyway.schemas= where schema_name is in caps
I have created checkpoint table ggate for replicat rep1 but still I am getting following error:
2014-09-04 23:38:21 ERROR OGG-00446 Oracle GoldenGate Delivery for
Oracle, REP1.prm: Checkpoint table ggate.checkpoint does not exist.
Please create the table or recreate the REP1 group using the correct
table.
2014-09-04 23:38:21 ERROR OGG-01668 Oracle GoldenGate Delivery for
Oracle, REP1.prm: PROCESS ABENDING.
Can anyone tell me how to resolve it?
In this kind of situations you should:
Have you actually run the ADD CHECKPOINTTABLE? if not run it
Check if the checkpoint table actually exists in the database - if it has been created - try to drop it (DROP CHECKPOINTTABLE) and recreate it (ADD CHECKPOINTTABLE)
Check if the checkpoint parameter is correctly set in the GLOBALS config file
Restart the MGR and Extract/Replicat processes
Verify if the user has access on the database to the checkpoint table (insert, update, delete rights)
If nothing works, run 10046 flag on the target database and check what the GoldenGate Replicat process is executing on the database and when it actually fails (what it wants to do on the database and try to do the same commands by yourself)
This is a simple troubleshooting initiative:
Are you using a traditional non-CDB database or a PDB?
Are you using Classic Architecture or Microservices Architecture? - Different approaches when adding a checkpoint table.
How are you running ADD CHECKPOINTTABLE? From GGSCI/AdminClient or from HTML5 page?
In Classic Architecture, do you have CHECKPOINTTABLE parameter set in GLOBALS? (CHECKPOINTTABLE [container.] owner.table)
Who are you logged into the database as when using DBLOGIN USERIDALIAS?
What replicat are you using? - Classic, Coordinated, Integrated, Parallel?
Check the schema where the table is suppose to be? If not there, you can query the DBA_TABLES view for the name of the checkpoint table and see who owns it.
A lot of times when the checkpint table cannot be created it is due to not updating the GLOBALS file and/or connecting as the correct user to the database.
While importing an oracle schema from dump file, i am getting below error while creating tables.
ORA-14102: only one LOGGING or NOLOGGING clause may be specified.
I see the above error while creating tables from the dumpfile for several tables.
How to enable or disable LOGGING/NOLOGGING at schema level before i start import?
When performing an Oracle database export with the expdp of Oracle 11gR2 (11.2.0.1) and then importing it into the database with impdp, the following error messages appear in the import log file:
ORA-39083: Object type INDEX failed to create with error:
ORA-14102: only one LOGGING or NOLOGGING clause may be specified
This is a known Oracle 11gR2 issue. The problem is that the DBMS_METADATA.GET_DDL returns invalid syntax for an index created. So, during the index creation, both the NOLOGGING and LOGGING keywords are visible in the DDL. Download and apply Patch 8795792 from Oracle to resolve this issue.
I have got most of the way but there seems to be a permissions issue somewhere:
Before the restore everything is working fine in my target environment - target has a server login account TCMDBUser which is mapped to my tridion_cm database user TCMDBUser
My source tridion_cm database has user TCMDBUser_DEV.
After restoring the source .bak into my target TCMDBUser_DEV is orphaned.
I edit the TRUSTEES table to correct MTSUser and my admin log accounts for my target environment and run the following to fix up my orphaned database user:
sp_change_users_login #Action='update_one',
#UserNamePattern='TCMDBUser_DEV',
#LoginName='TCMDBUser'
GO
I can log back in to Tridion explorer and see the expected list of publications and can walk through the tree structure but when I come to a folder which should contain items I see nothing with error:
and the corresponding event log error is:
Unable to get list of SDL Tridion Content Manager items.
DESCRIPTION
Error Code:
0x80040000 (-2147221504)
Call stack:
System.Data.ProviderBase.FieldNameLookup.GetOrdinal(String)
System.Data.SqlClient.SqlDataReader.GetOrdinal(String)
System.Data.SqlClient.SqlDataReader.get_Item(String)
Tridion.ContentManager.Data.AdoNet.DatabaseUtilities.ConvertToFieldDictionary(IDataRecord,IDictionary`2)
Tridion.ContentManager.Data.AdoNet.IdentifiableObjectDataMapper.Read(TcmUri,IDataRecord,IDictionary`2)
Tridion.ContentManager.Data.AdoNet.ContentManagement.OrganizationalItemDataMapper.GetListItemsPost(IDataReader,TcmUri,OrganizationalItemItemsFilterData)
Tridion.ContentManager.Data.AdoNet.ContentManagement.OrganizationalItemDataMapper.Tridion.ContentManager.Data.ContentManagement.IOrganizationalItemDataMapper.GetListItems(TcmUri,OrganizationalItemItemsFilterData)
Tridion.ContentManager.ContentManagement.OrganizationalItem.GetListItemsData(OrganizationalItemItemsFilter)
Tridion.ContentManager.ContentManagement.OrganizationalItem.GetListItemsStream(OrganizationalItemItemsFilter)
Tridion.ContentManager.BLFacade.ContentManagement.OrganizationalItemFacade.GetListItemsXml(UserContext,String,ListFilter,ListColumnFilter)
Tridion.ContentManager.BLFacade.ContentManagement.OrganizationalItemFacade.GetListData(UserContext,String,EnumListKind,ListColumnFilter,String)
Folder.GetListItems
You will need to delete/drop the TCMDBUser_DEV form the DB and then create a new one with the same name and password (or reattach it to your cm DB). That should fix your problem.
I normally use the delete method with MS SQL server. I believe this occurs due to the ownership status that the TCMDBUser has on the database Schema.
When complete your TCMDBUser user should have the following permissions on your Tridion_CM database
Like Chris mentioned, I always drop the user from the database and then assign the existing TCMDBUser in SQL Server the rights to the restored database. You can drop the user with the following command (on the restored database):
EXEC sp_dropuser TCMDBUser
Then through the SQL Server - Security - Logins, you request the properties of your TCMDBUser and in the User Mapping add the following database roles: db_datareader, db_datawriter and db_ddladmin.
That's what I've always done in the past and works for me, not sure if its all required, but worth a try I guess
Try creating new user TCMDBUser in the database and run the following command
EXEC sp_change_users_login 'Update_One', 'TCMDBUser', 'TCMDBUser'