We have a database on a server that is having performance issues, and a month into investigating I'm not finding anything different from our other servers (we even upgraded the hardware). However, there is a database with 47 Table Views, that I am 99% sure gets data into it constantly. Is it possible that the ludicrous number of Tabel Views set up are affecting normal server performance?By "Table Views", do you mean standard Views? The number of views should not impact performance. If data is constantly being inserted, then you may want to look at removing any indicies that are not needed as these can slow performance. Consider periodically rebuilding indicies and updating database statistics as well, as both of these can impact performance
Stev
-- Stephen M Accetta wrote: --
We have a database on a server that is having performance issues, and a month into investigating I'm not finding anything different from our other servers (we even upgraded the hardware). However, there is a database with 47 Table Views, that I am 99% sure gets data into it constantly. Is it possible that the ludicrous number of Tabel Views set up are affecting normal server performance?
Showing posts with label affect. Show all posts
Showing posts with label affect. Show all posts
Friday, March 23, 2012
How much do "Table Views" affect server performance on a whole?
We have a database on a server that is having performance issues, and a mont
h into investigating I'm not finding anything different from our other serve
rs (we even upgraded the hardware). However, there is a database with 47 Ta
ble Views, that I am 99% su
re gets data into it constantly. Is it possible that the ludicrous number o
f Tabel Views set up are affecting normal server performance?By "Table Views", do you mean standard Views? The number of views should not
impact performance. If data is constantly being inserted, then you may want
to look at removing any indicies that are not needed as these can slow perf
ormance. Consider periodica
lly rebuilding indicies and updating database statistics as well, as both of
these can impact performance.
Steve
-- Stephen M Accetta wrote: --
We have a database on a server that is having performance issues, and a mont
h into investigating I'm not finding anything different from our other serve
rs (we even upgraded the hardware). However, there is a database with 47 Ta
ble Views, that I am 9
9% sure gets data into it constantly. Is it possible that the ludicrous num
ber of Tabel Views set up are affecting normal server performance?
h into investigating I'm not finding anything different from our other serve
rs (we even upgraded the hardware). However, there is a database with 47 Ta
ble Views, that I am 99% su
re gets data into it constantly. Is it possible that the ludicrous number o
f Tabel Views set up are affecting normal server performance?By "Table Views", do you mean standard Views? The number of views should not
impact performance. If data is constantly being inserted, then you may want
to look at removing any indicies that are not needed as these can slow perf
ormance. Consider periodica
lly rebuilding indicies and updating database statistics as well, as both of
these can impact performance.
Steve
-- Stephen M Accetta wrote: --
We have a database on a server that is having performance issues, and a mont
h into investigating I'm not finding anything different from our other serve
rs (we even upgraded the hardware). However, there is a database with 47 Ta
ble Views, that I am 9
9% sure gets data into it constantly. Is it possible that the ludicrous num
ber of Tabel Views set up are affecting normal server performance?
Monday, March 12, 2012
How long to create a non-clustered index?
I need to know how long it will take to create a non-clustered index given:
I know how many columns the index will affect, the column width in bytes, how many rows, an average row size, the number of hard disks, their speed in RPM, and they are setup in RAID 5.
Thanksdepends on lots of stuff|||What else do you need to know?|||there are too many variables. it could be 2 seconds to x number of hours. Hardware. configuration. is the table a terabyte in size or a megabyte in size. Is the column an int or varchar etc...(numbers process faster), what is already happening on the machine. Are the moons of saturn in alignment. is there a MLB conspiracy to have the cubs win the series this year now that red sox won.
just do it. if you are worried about what is going to ahppen to the computer, do it when everyone goes home or schedule it as job to run at midnight.|||The non-clustered index is created on 10 columns - each 100 bytes wide. The table is 6 X 10^6 rows and average 2000 bytes per row - so 12 X 10^9 bytes total. I have 5 15,000 RPM disks in RAID 5.
Take everything else out of the picture. I just need a mathematical way to estimate a best case/worst case scenario.|||I just need a mathematical way to estimate a best case/worst case scenario.
No you don't.
It's a bad idea in the first place
Don't do it.|||Can you explain how you came to this humble conclusion?|||I am tiddy bit curious about why anyone would need a 10 column index but I decided to keep my mouth shut.|||if memory serves (and it often does'nt) multi column idexes only do any good if all of the columns are searched in the same query and are queried in the same order that they appear in the index.
Seems to me something like this would be a performance hit on inserts and deletes and updates and such.
Am I close Brett.|||Can you explain how you came to this humble conclusion?
Let's see, a thousand byte + wide index...
I would think that would be very ineffecient.
Also, if you needed anything else from the row, I imagine, the optimizer might choose to ignore it anyway.
humble, not humble, whatever, it has nothing to do with it.
It's a bad idea.
Post the DDL of this table.
And who told you that you need that index?|||Seems to me something like this would be a performance hit on inserts and deletes and updates and such.
:eek:
Ya think?
Am I close to Brett.
Let's not start picking out wallpaper or anything... :)
But if you're buying...I'll have a 'rita on the rocks... :D
I know how many columns the index will affect, the column width in bytes, how many rows, an average row size, the number of hard disks, their speed in RPM, and they are setup in RAID 5.
Thanksdepends on lots of stuff|||What else do you need to know?|||there are too many variables. it could be 2 seconds to x number of hours. Hardware. configuration. is the table a terabyte in size or a megabyte in size. Is the column an int or varchar etc...(numbers process faster), what is already happening on the machine. Are the moons of saturn in alignment. is there a MLB conspiracy to have the cubs win the series this year now that red sox won.
just do it. if you are worried about what is going to ahppen to the computer, do it when everyone goes home or schedule it as job to run at midnight.|||The non-clustered index is created on 10 columns - each 100 bytes wide. The table is 6 X 10^6 rows and average 2000 bytes per row - so 12 X 10^9 bytes total. I have 5 15,000 RPM disks in RAID 5.
Take everything else out of the picture. I just need a mathematical way to estimate a best case/worst case scenario.|||I just need a mathematical way to estimate a best case/worst case scenario.
No you don't.
It's a bad idea in the first place
Don't do it.|||Can you explain how you came to this humble conclusion?|||I am tiddy bit curious about why anyone would need a 10 column index but I decided to keep my mouth shut.|||if memory serves (and it often does'nt) multi column idexes only do any good if all of the columns are searched in the same query and are queried in the same order that they appear in the index.
Seems to me something like this would be a performance hit on inserts and deletes and updates and such.
Am I close Brett.|||Can you explain how you came to this humble conclusion?
Let's see, a thousand byte + wide index...
I would think that would be very ineffecient.
Also, if you needed anything else from the row, I imagine, the optimizer might choose to ignore it anyway.
humble, not humble, whatever, it has nothing to do with it.
It's a bad idea.
Post the DDL of this table.
And who told you that you need that index?|||Seems to me something like this would be a performance hit on inserts and deletes and updates and such.
:eek:
Ya think?
Am I close to Brett.
Let's not start picking out wallpaper or anything... :)
But if you're buying...I'll have a 'rita on the rocks... :D
Subscribe to:
Posts (Atom)