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.