97 reputation
7
bio website
location
age
visits member for 2 years, 6 months
seen Oct 14 at 15:42

Sep
18
revised Auditing the View Server State permissions on Server
added 87 characters in body
Sep
18
comment Auditing the View Server State permissions on Server
Thanks. This is an option but we were looking more for an already existing consolidated package/event in SQL Server that we normally could look up in dm_xe_packages and/or dm_xe_objects instead of auditing every DMV SQL texts filtered on DMV's that hits the server. Thanks again for your input on this. I should have been more clear on my question with this and I will fix it.
Sep
18
comment Auditing the View Server State permissions on Server
SQL 2008 Enterprise. Thanks again
Sep
17
revised Auditing the View Server State permissions on Server
added 87 characters in body
Sep
17
comment Auditing the View Server State permissions on Server
Thanks. Appreciate your input. But we are looking for specifically monitoring the DMV's that are accessed by all users and not all sql texts that are executed by all users. We don't want the auditing to be any resource intensive either. Most probably this permissions was added as one time for some user but unfortunately it was added to the wrong group which apparently gave access to all users. Of course we could just revoke the view server state and take the impact or if there is a particular event that we could use to get an idea as to who is accessing all DMV that would be ideal.
Sep
16
asked Auditing the View Server State permissions on Server
Sep
2
awarded  Popular Question
Jul
2
awarded  Curious
Feb
6
comment AlwaysOn Availability Groups Delayed Replica
Thanks. I agree. I would definitely be more comfortable using the LS approach as I could restore to the point of time on the secondary just before the damage happened on the primary.
Feb
6
comment AlwaysOn Availability Groups Delayed Replica
Thanks Brent. Appreciate your input. I have used snapshot as a measure for pre-batch processing and has helped a lot.
Feb
6
comment AlwaysOn Availability Groups Delayed Replica
Thanks. There have been articles where people have argued why log shipping should be considered at all with AO in place. I have worked a lil with mongodb and you can make a member as a delayed to enable this functionality. I think it is good to have feature especially when AO allows to run in asynchronous mode for the secondaries, so why wouldn't a delay be added as well :-)
Feb
6
asked AlwaysOn Availability Groups Delayed Replica
Apr
16
comment Reclaiming space from a large partitioned database
Thanks. I would agree if it is for future partitions but the one we are reclaiming is are older partitions. That data is static and does not grow. Data can be deleted but no new data will be added
Apr
16
comment Reclaiming space from a large partitioned database
Nope. Did not do one transaction. Rebuild an index on a partition is one transaction unless you know of a way to split that transaction? So basically, one of these partitions was huge with lot of data and hence the log was filled up...I really appreciate your comments
Apr
16
comment Reclaiming space from a large partitioned database
Thanks Mike. Lots of data were deleted from the older partition. To free up that space, When we did shrink of the older partition(s)/filegroups, obviously the FG's got fragmented to 90%. So we had to do a index rebuild which made the log size grow very big and cause the tran log to almost fill in bulk model. We do have trean log backups every few seconds but yet, the size of the tran file was too big. To minimise the issue with tran logs, we changed to simple to help with the index rebuild which broke the logshipping. We have it running now but was wondering what if db was 5TB database. Thx
Apr
16
comment Reclaiming space from a large partitioned database
Aaron, yes the DB will grow again but not on the older partitions. The large space we got when deleting the data was in the older partitions and yes, it is a lot.
Apr
16
comment Reclaiming space from a large partitioned database
The whitespace is created in the older partition for the years 2011 and 2012 which would never grow :-(. Hence the need to reclaim the sapce
Apr
16
comment Reclaiming space from a large partitioned database
Thanks. This is exactly what are currently doing. But we noticed that the space we gained from the older partitions during the shrink operation were used by the index rebuild in those older date partition. So now, we have that extra space in each of those older partition which is such a waste. I understand if we are going to use the space in the future and hence there is no need to shrink the DB again. The idea was to reclaim the space on the older partitions. What are your thoughts on the logshipping question? Thanks for your time and help
Apr
16
comment Reclaiming space from a large partitioned database
No..The partition where the space will be reclaimed is for older dates and data wont grow again there. Filegroup option is tedious process and requires especially for the size of the database we have. Appreciate your comments
Apr
15
asked Reclaiming space from a large partitioned database