We try to build an SLT (SAP Landscape Transformation) Configuration which replicates one Table "new3_asdf" and one view on top of this table: new3_asdf_view_id.
So in transaction LTRS I added the view to the table:
In LTRC I added the table new3_asdf to replication. Even though there is no 'X' in column failed the replication does not work :((
The 'View Errors' Button reveals the Error / Cause:
Migration object Z_NEW3_ASDF_035 has been deleted due to changes in table definition
How can I recreate it according to the Help Text:
Source and destination databases are DB2 10.5
I have seen this error when you change the table structure in LTRS while the job is replicating in LTRC. It appears to drop the target table, making your replication job fail because you have no target. You have to have all your LTRS table config in place before LTRC or this message can happen.
Related
i want to know if it's possible to drop a table fragment that is not letting me perform a restore with the NDB_RESTORE tool.
When i run the restore, it throws the following error:
Create table db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion failed: 721: Schema object with given name already exists
Restore: Failed to restore table: db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion ... Exiting
NDBT_ProgramExit: 1 - Failed
I have already drop the DB_DIED_MAESTRO database previous to run the restore, but this fragment is not being dropped along with the database.
I have check that the fragment is in the database catalog using this querys:
*select * from ndbinfo.operations_per_fragment
where fq_name like 'db_died_maestro%'*
query result
And this query:
*select * from ndbinfo.memory_per_fragment
where fq_name like '%FKM_3194_0_mae_tipo_reg_evaluacion'*
query 2 result
This fragment was created on a previous run of the NDB_RESTORE tool. Please help me.
The table is a foreign key 'mock' table (indicated by the name NDB$FKM prefix).
Foreign key mock tables are created transiently in some cases to implement the foreign_key_checks = 0 feature of MySQL. This feature requires storage engines to support unordered creation of tables with partially defined foreign key constraints which can be abritrarily enabled (without revalidation) at a later time.
Foreign key mock tables are normally entirely managed by the Ndb storage engine component of MySQL, and so should not be visible unless there has been a failure or bug of some kind.
If you can share information about activities occurring before this problem then that would help us understand how this happened and whether it can be avoided.
As a workaround it should be possible for you to use the ndb_drop_table utility to drop this table, before re-attempting the failing restore. You may have to escape the $ in the name passed as a command line argument from a shell. Probably you should check for any other NDB$FKM tables in a similar situation.
Situation: We wan to to real-time ETL using SLT (SAP Landscape Transformation) Replication Server.
I learned that I have to define views in transaction LTRS.
So I try to add a view to an existing Table like in the Screenshot. Unfortunately I get the Error: SQL0601N The name of the object to be created is identical to the existing name ...
Make sure that you use transaction LTRS before adding the table to the configuration in transaction LTRC.
Another cause could be that the table exists in the target database. So make sure that the target table does not exist yet.
On tests about the issue I realized that transaction LTRS where the error occurs does not create a table - even though the error message indicates otherwise.
I have an existing table in the DB that was created with the parameter #supports_net_changes set to 0. Hence there is only one function for that table i.e. to get all changes fn_cdc_get_all_changes_dbo_.
How do I now enable the get_net_changes function over it? Do I have to drop existing cdc and the re-create? Haven't been able to get conclusive help on this
I have understood the error. When disabling the existing cdc on table the table name of the captureinstance needed to be properly specified. This was causing the failure and hence I was unable to get the net changes implemented.
I have encountered a problem after i changed my DSN from POC server to point to my new Testing server without realizing that both environment tables columns are not in sync. There are 2 columns missing in my POC server which exist in both Test and Production server.
After i re-pointed the Universe's DSN to the test server, how do i refresh the existing table in my universe to auto refresh the 2 missing columns? Below is what i have tried:
I tried to drag the missing columns into the existing table but it was not allowed.
I tried to delete the existing table and drag out the entire table with same name, the 2 missing columns finally appears, but it create more issues as all my existing dimensions created were screwed up due to an "Unresolved table". It seems that it found that the original table was deleted and the new one is not matched.
There is no refresh table function available.
Please advise. Thanks.
Select the table, then hit View->Refresh Structure.
I'm trying to re-index the category flat data, but I am always met with the same error:
There was a problem with reindexing process. Error Message: SQLSTATE[HY000]: General error: 1005 Can't create table 'xxx.catalog_category_flat_store_6' (errno: 121)
The table doesn't exist, there is a 1 and a 7. Not sure if that makes a difference?
After running the query manually through phpMyAdmin, I am met with the MySQL error 121. I've checked around and this would suggest the names of the foreign keys trying to be created already exist. I've listed all foreign keys in the DB right now, and they don't exist at all.
I've also tried running SHOW ENGINE INNODB STATUS on the DB for more information, but we don't have the rights to view that apparently.
After getting the priv's updated so we could run SHOW INNODB STATUS, we discovered that we already had an existing index that was attempting to be duplicated with this new table. This stemmed from us backing up an older version of the table that was trying to be created. Deleting that copy of the table enabled Magento to re-index properly and solved our problem.
Try logging the sql commands and debug what its trying to do by executing them manually. On the index process, normally there is a command that clears a table, and another to recreate it.
Edit /magentoRoot/lib/Varien/Db/Adapter/Pdo/Mysql.php and change $_debug to true and note the $_debugFile location (should be var/debug/pdo_mysql.log)
Its best to edit the file in vi, have a browser open to reindex JUST the category data, save the file in vi :w! and then run the indexer then change the debug back to false.
Then go read the log. It may help.