Reputation
Top tag
Next privilege 200 Rep.
See reduced ads
Badges
7
Impact
~6k people reached

  • 0 posts edited
  • 0 helpful flags
  • 2 votes cast
Apr
23
comment SSMS Registered Servers with ReadOnly Application Intent
Hi jyao, Thanks for your reply. You have posted an interested powershell script in that article but unfortunately does not work with ApplicationIntent property. I changed the PS to use the following: New-Item -Name $(encode-sqlname $g.value) -path "sqlserver:\SQLRegistration\$($choice)\$($g.parentfolder)" -ItemType $g.type -Value ("Server=$regsrv ; integrated security=true;Initial Catalog=dbname;ApplicationIntent=ReadOnly"); No luck! If this would work, I would have more than happy to use this as an option. Thanks again.
Apr
17
comment SQL Server Management Studio with Multi subnet HADR cluster
Jeremy, the above Microsoft link status is now closed but the solution still does not work :-(
Apr
16
asked SSMS Registered Servers with ReadOnly Application Intent
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
Aug
30
revised Incremental Database/Data Change Restore
deleted 30 characters in body
Aug
30
comment SQL Partioning on date, how does it work for future records?
Perhaps you could write a script with logic to alter the schemes and functions for the object(s) using split option and scheduling this script to occur every quarter/calendar/fiscal for the partitioned object?
Aug
30
comment Incremental Database/Data Change Restore
~100MB *The project manager stated it will grow(?) over the month and so he is looking for all the options out there.This is really in a premature state as we just got the product a week back. * That was one of the quesiton I had for them. I will know more soon *No *No. We thought of linked servers etc but our business units want this in-house "only". *FYI:They wil run the daily batch on their site and send us the EOD data for us. Currently they are sending as .bak as the DB size is very small. Like I said, we are planning for the future.I really appreciate your time and input on this