This risk can be mitigated with proper testing. In order to make sure that this setting doesn’t have destructive effects, I strongly recommend to store the timezone that was used in the session. There is a risk that a timezone is set on session level. An ELT-tool should be used for production loads. The workaround I recommend is to set the timezone explicitly in the session where data is loaded. In case the timezone changes due to new insights, the ACCOUNTADMIN needs to be aware of that changing the timezone can cause new TS_LTZ timestamps to get corrupted. The Snowflake ACCOUNTADMIN has the rights to change the timezone on the production Snowflake account.Therefore, there is no risk that corrupted LTZ timestamps are loaded. However, they should not be privileged to load data into snowflake tables. A Snowflake-developer can change the sessions timezone.There are three scenario’s that I can think of that can cause this to happen. The only way that LTZ Timestamps can get corrupted is when the session timezone accidentally overwrites the account timezone.Corrupted LTZ Timestamps only impact the production account.I agree with Randy that this risk exists, but at the same time I would assess its probability to be low:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |