Home Forums SQL Server 2012 SQL 2012 - General Two tables, exact same structure but with different names, behave differently while performing mass updates. RE: Two tables, exact same structure but with different names, behave differently while performing mass updates.

  • subramaniam.chandrasekar - Tuesday, December 26, 2017 10:55 PM

    Jay-45986 - Tuesday, December 26, 2017 1:56 PM

    These are quiet large databases, terabytes of data. So recreating it by scripting out the objects and then loading the data using SSIS or TSQL can be extremely time consuming and error-prone. 

    The idea is to de-identify this data in the lower environments (dev, staging, uat etc)  I will be given a backup of a prod db, which is this exact database as the db/table(s) in question. I restore it and then use the tool to de-identify any PII or PHI data. I simply do not have the luxury of recreating and reloading everything, as these multiple requests would be coming in down the pipeline to restore/purge data on daily basis.

    I have however, restored the exact same db and repeated the steps detailed in the original post on totally different box, with the same results.  

    I just wanted to know, whether anybody has dealt with something similar in the past? So let's just say for arguments sake that I am correct with having two tables (one existing, one new), same exact structure, same # of rows, but they behave differently while being mass loaded. Does it make sense? I just want to make sure that I haven't left a stone unturned with respect to troubleshooting this. 

    If you would like to see the DDL of the tables, I could share that as well.

    Were they any rebuild indexes that had happened on the original table ? (22 rows/sec), If not, Check for any backup jobs or maintenance jobs activity was happened at the same time of execution ? Could you please retry your operation and let us know whether you've got the same results on Original (22 rows/sec) & Duplicate ( 645 rows/sec).

    Indexes are disabled on BOTH of the tables, including any and all fk constraints.