Hi @DineshOjha,

This is expected behaviour. DEEP CLONE is designed for tables, so it works well for keeping Delta tables in sync to a DR environment. The public docs describe clone as creating a copy of a source table at a specific version, and they also note that some object types, such as materialised views, are not supported as either source or target.

For views, the recommended pattern is usually to treat them as deployment artefacts rather than data assets. In other words:

• Use DEEP CLONE to replicate the underlying Delta tables to DR
• Keep the view definitions in source control or your deployment tooling
• Recreate the views in DR with CREATE OR REPLACE VIEW after the table clone step completes

That approach tends to be the cleanest for DR because views are logical definitions over tables, not physical data copies.

A simple way to think about it is:

• tables → cloned
• views → redeployed

So if you already have jobs or CI/CD promoting objects into production, I'd recommend extending that same process to publish the view DDL into the DR environment as well, after the table sync finishes.

If it helps, I'd summarise the guidance as...use Deep Clone for the data layer, and manage the semantic layer (views) as code that gets recreated in DR.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

Thank you Ashwin

We have implemented CI/CD pipeline to deploy the jobs, but it doesn't run the jobs.

The jobs which load the data/create the tables need to run at specific times and so that is handled by a separate scheduling tool. In such a scenario, if we add a view creation in the scheduler, that would be redundant as the views need to be created just once. Any suggestions/recommendations on this? 

Hi @DineshOjha,

Got it...that makes sense. If the views are logical objects that only need to be created once, I would treat them differently from the regularly scheduled table-refresh process.

My recommendation is to add a lightweight deployment step for metadata objects, such as views, separate from the scheduler. For example, you can use DEEP CLONE for the underlying Delta tables and then create the views as part of environment provisioning or deployment, not as part of the recurring schedule. You can then rerun the view DDL only when the definition changes, or when you are standing up or rebuilding the DR environment

That is generally not considered redundant, because a standard view does not process or write data. Databricks describes a view as a virtual table with no physical data, and creating a view just registers the query text in the metastore.

One option is to add a small post-provisioning SQL step in CI/CD that runs after the DR tables are available. For the initial creation, CREATE VIEW or CREATE VIEW IF NOT EXISTS is fine.

If you later need to change the definition of an existing view, one important nuance is that CREATE OR REPLACE VIEW replaces the existing view and does not preserve privileges granted on the original view. If you want to preserve grants while updating the definition, the docs recommend using ALTER VIEW ... AS ....

Hope this helps.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.