Post reply

Implementing Stretch Database

  • January 15, 2019 at 12:08 am

    #416628

    Comments posted to this topic are about the item Implementing Stretch Database

  • January 15, 2019 at 9:40 am

    #2018951

    Wow! Interesting. Anyone using this?

    Doodles

  • January 15, 2019 at 10:52 am

    #2018965

    Micorosoft in the beginning 😉

  • January 15, 2019 at 10:37 pm

    #2019031

    Thanks for the article, Deepak.

    I may have missed this in the article but what determines what rows stay on prem and what rows stay in the cloud by default.

    And based on experience, can anyone estimate to what extent performance is impacted by a poor Internet connection when querying rows in the cloud? 

    Br. Kenneth Igiri
    https://kennethigiri.com
    All nations come to my light, all kings to the brightness of my rising

  • January 16, 2019 at 6:25 am

    #2019064

    Welcome Ken!

    I think by default,table data is separated into Hot Data(that is frequently accessed) & Cold Data(rarely or almost never accessed data).So hot data stay on prem and cold data is moved to Azure.
    From performance perspective, I have not encountered any issues as mainly dealt with the historic data on cloud.
    Thanks,
    Deepak.

  • January 16, 2019 at 7:13 am

    #2019079

    Deepak Sahu - Wednesday, January 16, 2019 6:25 AM

    Welcome Ken!

    I think by default,table data is separated into Hot Data(that is frequently accessed) & Cold Data(rarely or almost never accessed data).So hot data stay on prem and cold data is moved to Azure.
    From performance perspective, I have not encountered any issues as mainly dealt with the historic data on cloud.
    Thanks,
    Deepak.

    Thanks. Makes sense.

    Br. Kenneth Igiri
    https://kennethigiri.com
    All nations come to my light, all kings to the brightness of my rising

  • January 16, 2019 at 8:50 am

    #2019106

    Good write up Deepak. Never knew it's that simple to implement. Any pitfalls/limitations and GOTCHAs to be aware of based on your experience?

  • July 3, 2020 at 10:48 am

    #3767307

    It's not that simple. There are a number of pitfalls that are dangerous. PRIMARY KEY or UNIQUE cannot be defined for the table. Foreign Key has some limitations. All some restrictions, which means that all the SELECT statements referencing the table may need to be rewritten due to the poorer data quality. This will result in poorer performance, because you must test in the SELECT-statement for uniqueness and foreign keys - DISTINCT, OUTER JOIN instead of INNER JOIN, ....

    You can't UPDATE or DELETE rows that have been migrated, or rows that are eligible for migration, in a Stretch-enabled table or in a view that includes Stretch-enabled tables.

    MS claims in their documentation that it is without any changes to queries - it can be dangerous!

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply