Will frequent creation and deletion of TABLE (not indexes) cause fragmentation in database?
Does frequent creation and deletion of physical table in database causes fragmentation? I am frequently creating and deleting database for loading data warehouse load. I am using these table to hold records temporarily for batch updates.
This question is asked primarily from SQL Server 2016 and Azure Data Warehouse (MPP) point of view. But i would like to extend this question for any databases (if true)
sql-server table fragmentation
New contributor
add a comment |
Does frequent creation and deletion of physical table in database causes fragmentation? I am frequently creating and deleting database for loading data warehouse load. I am using these table to hold records temporarily for batch updates.
This question is asked primarily from SQL Server 2016 and Azure Data Warehouse (MPP) point of view. But i would like to extend this question for any databases (if true)
sql-server table fragmentation
New contributor
>>>creation and deletion of physical table<<< do you mean delete or drop table?
– sepupic
12 hours ago
If this is a concern for you just create it on its own file group so it has no impact at all on other data files
– Martin Smith
12 hours ago
How would you measure this fragmentation?
– Erik Darling
12 hours ago
add a comment |
Does frequent creation and deletion of physical table in database causes fragmentation? I am frequently creating and deleting database for loading data warehouse load. I am using these table to hold records temporarily for batch updates.
This question is asked primarily from SQL Server 2016 and Azure Data Warehouse (MPP) point of view. But i would like to extend this question for any databases (if true)
sql-server table fragmentation
New contributor
Does frequent creation and deletion of physical table in database causes fragmentation? I am frequently creating and deleting database for loading data warehouse load. I am using these table to hold records temporarily for batch updates.
This question is asked primarily from SQL Server 2016 and Azure Data Warehouse (MPP) point of view. But i would like to extend this question for any databases (if true)
sql-server table fragmentation
sql-server table fragmentation
New contributor
New contributor
New contributor
asked 14 hours ago
Ravikumar VRavikumar V
1
1
New contributor
New contributor
>>>creation and deletion of physical table<<< do you mean delete or drop table?
– sepupic
12 hours ago
If this is a concern for you just create it on its own file group so it has no impact at all on other data files
– Martin Smith
12 hours ago
How would you measure this fragmentation?
– Erik Darling
12 hours ago
add a comment |
>>>creation and deletion of physical table<<< do you mean delete or drop table?
– sepupic
12 hours ago
If this is a concern for you just create it on its own file group so it has no impact at all on other data files
– Martin Smith
12 hours ago
How would you measure this fragmentation?
– Erik Darling
12 hours ago
>>>creation and deletion of physical table<<< do you mean delete or drop table?
– sepupic
12 hours ago
>>>creation and deletion of physical table<<< do you mean delete or drop table?
– sepupic
12 hours ago
If this is a concern for you just create it on its own file group so it has no impact at all on other data files
– Martin Smith
12 hours ago
If this is a concern for you just create it on its own file group so it has no impact at all on other data files
– Martin Smith
12 hours ago
How would you measure this fragmentation?
– Erik Darling
12 hours ago
How would you measure this fragmentation?
– Erik Darling
12 hours ago
add a comment |
1 Answer
1
active
oldest
votes
There are quite a lot of factors as to whether the staging table will be fragmented, and if so, how much. The most obvious that come to mind are:
- How much data is being added to the table
- How much other tables are adding or deleting rows at the same time
- Where exactly in the database file the table was created and if there are a lot of contiguous free extents
So basically, the answer is that it is quite likely that the table will be fragmented. They won't necessarily cause your other permanent files to be fragmented much, but again, if they are growing and need new extents, then yes.
All that said, the more important questions are:
- Does the fragmentation cause a performance problem? Not likely. Fragmentation is not the problem it used to be when you had 3 hard drives in a RAID 5 array. On Azure your data is using 100s of disks, so the combined read and write power reduces the performance impact of fragmentation to almost nil. See Top Worrying About SQL Server Fragmentation"
- Is there anything I can do about it? Nothing reasonable. You could rebuild your other tables and indexes with a lower fill factor and that may stop them from becoming fragmented as much if data is being inserted into someplace other than then end of the table (which might indicate poor table design), but again, see point above.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Ravikumar V is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f227474%2fwill-frequent-creation-and-deletion-of-table-not-indexes-cause-fragmentation-i%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are quite a lot of factors as to whether the staging table will be fragmented, and if so, how much. The most obvious that come to mind are:
- How much data is being added to the table
- How much other tables are adding or deleting rows at the same time
- Where exactly in the database file the table was created and if there are a lot of contiguous free extents
So basically, the answer is that it is quite likely that the table will be fragmented. They won't necessarily cause your other permanent files to be fragmented much, but again, if they are growing and need new extents, then yes.
All that said, the more important questions are:
- Does the fragmentation cause a performance problem? Not likely. Fragmentation is not the problem it used to be when you had 3 hard drives in a RAID 5 array. On Azure your data is using 100s of disks, so the combined read and write power reduces the performance impact of fragmentation to almost nil. See Top Worrying About SQL Server Fragmentation"
- Is there anything I can do about it? Nothing reasonable. You could rebuild your other tables and indexes with a lower fill factor and that may stop them from becoming fragmented as much if data is being inserted into someplace other than then end of the table (which might indicate poor table design), but again, see point above.
add a comment |
There are quite a lot of factors as to whether the staging table will be fragmented, and if so, how much. The most obvious that come to mind are:
- How much data is being added to the table
- How much other tables are adding or deleting rows at the same time
- Where exactly in the database file the table was created and if there are a lot of contiguous free extents
So basically, the answer is that it is quite likely that the table will be fragmented. They won't necessarily cause your other permanent files to be fragmented much, but again, if they are growing and need new extents, then yes.
All that said, the more important questions are:
- Does the fragmentation cause a performance problem? Not likely. Fragmentation is not the problem it used to be when you had 3 hard drives in a RAID 5 array. On Azure your data is using 100s of disks, so the combined read and write power reduces the performance impact of fragmentation to almost nil. See Top Worrying About SQL Server Fragmentation"
- Is there anything I can do about it? Nothing reasonable. You could rebuild your other tables and indexes with a lower fill factor and that may stop them from becoming fragmented as much if data is being inserted into someplace other than then end of the table (which might indicate poor table design), but again, see point above.
add a comment |
There are quite a lot of factors as to whether the staging table will be fragmented, and if so, how much. The most obvious that come to mind are:
- How much data is being added to the table
- How much other tables are adding or deleting rows at the same time
- Where exactly in the database file the table was created and if there are a lot of contiguous free extents
So basically, the answer is that it is quite likely that the table will be fragmented. They won't necessarily cause your other permanent files to be fragmented much, but again, if they are growing and need new extents, then yes.
All that said, the more important questions are:
- Does the fragmentation cause a performance problem? Not likely. Fragmentation is not the problem it used to be when you had 3 hard drives in a RAID 5 array. On Azure your data is using 100s of disks, so the combined read and write power reduces the performance impact of fragmentation to almost nil. See Top Worrying About SQL Server Fragmentation"
- Is there anything I can do about it? Nothing reasonable. You could rebuild your other tables and indexes with a lower fill factor and that may stop them from becoming fragmented as much if data is being inserted into someplace other than then end of the table (which might indicate poor table design), but again, see point above.
There are quite a lot of factors as to whether the staging table will be fragmented, and if so, how much. The most obvious that come to mind are:
- How much data is being added to the table
- How much other tables are adding or deleting rows at the same time
- Where exactly in the database file the table was created and if there are a lot of contiguous free extents
So basically, the answer is that it is quite likely that the table will be fragmented. They won't necessarily cause your other permanent files to be fragmented much, but again, if they are growing and need new extents, then yes.
All that said, the more important questions are:
- Does the fragmentation cause a performance problem? Not likely. Fragmentation is not the problem it used to be when you had 3 hard drives in a RAID 5 array. On Azure your data is using 100s of disks, so the combined read and write power reduces the performance impact of fragmentation to almost nil. See Top Worrying About SQL Server Fragmentation"
- Is there anything I can do about it? Nothing reasonable. You could rebuild your other tables and indexes with a lower fill factor and that may stop them from becoming fragmented as much if data is being inserted into someplace other than then end of the table (which might indicate poor table design), but again, see point above.
edited 11 hours ago
answered 11 hours ago
Tony HinkleTony Hinkle
1,8421418
1,8421418
add a comment |
add a comment |
Ravikumar V is a new contributor. Be nice, and check out our Code of Conduct.
Ravikumar V is a new contributor. Be nice, and check out our Code of Conduct.
Ravikumar V is a new contributor. Be nice, and check out our Code of Conduct.
Ravikumar V is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f227474%2fwill-frequent-creation-and-deletion-of-table-not-indexes-cause-fragmentation-i%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
>>>creation and deletion of physical table<<< do you mean delete or drop table?
– sepupic
12 hours ago
If this is a concern for you just create it on its own file group so it has no impact at all on other data files
– Martin Smith
12 hours ago
How would you measure this fragmentation?
– Erik Darling
12 hours ago