Because of that risk, it's better to redesign on this scale after the data warehouse migration.Įven if a data model is intentionally changed as part of the overall migration, it's good practice to migrate the existing model as-is to Azure Synapse, rather than do any re-engineering on the new platform.

Making data model changes here could also affect upstream or downstream ETL jobs to other systems. This approach carries a higher risk because it changes multiple factors simultaneously, making it difficult to compare the outcomes of the old system versus the new. Companies often see an opportunity to further modernize or transform their data during an ETL migration. This question comes up frequently because companies may want to lower the impact of changes on the data warehouse data model to improve agility. What is the best migration approach to minimize risk and impact on users? For more information, see Teradata log history. If logging is enabled and the log history is accessible, other information, such as SQL query text, is available in table DBQLogTbl and associated logging tables. LastAlterTimeStamp, AccessCount, LastAccessTimeStamp Here's an example query on DBC.Tables that provides the date of last access and last modification: SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName, If enabled, Teradata system catalog tables and logs contain information that can determine when a given table was last accessed-which can in turn be used to decide whether a table is a candidate for migration. It's best to use system metadata and log files rather than documentation to determine which tables are in use, because documentation can be out of date. Tables that aren't active can be archived rather than migrated, so that the data is available if necessary in future. It makes sense to only migrate tables that are in use in the existing system.

In legacy systems, it's not unusual for tables to become redundant over time-these don't need to be migrated in most cases.

Teradata database for mac