(Bugfix!) Adjust date condition for data partitioning process#10302
(Bugfix!) Adjust date condition for data partitioning process#10302ThisUsernameWasNotTaken wants to merge 1 commit intoMicrosoftDocs:livefrom
Conversation
After trying the example i had to change this condition because the logical partitioning system of the sql server will sort rows into their partition this way too internally. It became obvious after spamming inserts and split commands with identical time values since the precision of datetime2 required by this example project is ambiguous for rapidly retrieved SYSDATETIME() values. Regardless of transaction safety. If too fast its gets ambiguous. ie. two identical values for two seperate calls to SYSDATETIME().
|
@ThisUsernameWasNotTaken : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
prmerger-automator
bot
added
Change sent to author
in-memory-oltp/subsvc
sql/svc
labels
|
Learn Build status updates of commit 71994f8: ✅ Validation status: passed
For more details, please refer to the build report. |
There was a problem hiding this comment.
Pull request overview
Updates the T-SQL sample in the In-Memory OLTP partitioning pattern article to adjust the boundary condition used when offloading rows and when creating the staging table’s CHECK constraint, aiming to avoid issues with identical datetime2 boundary values during rapid SYSDATETIME() usage.
Changes:
- Change offload predicates from
<= @splitdateto< @splitdatefor both the INSERT and DELETE. - Change the staging CHECK constraint from
so_date > @splitdatetoso_date >= @splitdate. - Add an inline NOTE describing potential partition boundary duplication errors.
...nal-databases/in-memory-oltp/application-pattern-for-partitioning-memory-optimized-tables.md
Show resolved
Hide resolved
...nal-databases/in-memory-oltp/application-pattern-for-partitioning-memory-optimized-tables.md
Show resolved
Hide resolved
...nal-databases/in-memory-oltp/application-pattern-for-partitioning-memory-optimized-tables.md
Show resolved
Hide resolved
...nal-databases/in-memory-oltp/application-pattern-for-partitioning-memory-optimized-tables.md
Show resolved
Hide resolved
|
Can you review the proposed changes? Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
prmerger-automator
bot
added
the
aq-pr-triaged
|
#sign-off |
|
Invalid command: '#sign-off'. Only the assigned author of one or more file in this PR can sign off. @MikeRayMSFT |
After trying the example i had to change this condition because the logical partitioning system of the sql server will sort rows into their partition this way too internally. It became obvious after spamming inserts and split commands with identical time values since the precision of datetime2 required by this example project is ambiguous for rapidly retrieved SYSDATETIME() values. Regardless of transaction safety. If too fast its gets ambiguous. ie. two identical values for two seperate calls to SYSDATETIME().