Hey there! KimberlyLTripp is using Twitter.

Twitter is a free service that lets you keep in touch with people through the exchange of quick, frequent answers to one simple question: What are you doing? Join today to start receiving KimberlyLTripp's tweets.

Already using Twitter
from your phone? Click here.

KimberlyLTripp

#sqlconn @SQLvariant VLFs should be 16 per 8GB. Exact *max* depends. If file is small 100s is very bad. If the file is large, it depends. 12:45 PM Nov 13th from TweetDeck
#sqlconn Some people said they liked my troubleshooting (and especially the explanation) on showing what was wrong. So, in the end was OK. 12:52 PM Nov 12th from TweetDeck
@buckwoody Yeah, I have that two... helps if I had run it. 12:51 PM Nov 12th from TweetDeck in reply to buckwoody
#sqlconn #sqlpass Just blogged about the SQL Server MVP Deep Dives title (with a pic from launch at PASS): http://bit.ly/42YNDj. Enjoy! 12:50 PM Nov 12th from TweetDeck
#sqlconn See Part 9 of my msdn webcast. The entire thing is about creating server-side traces: http://bit.ly/2RWVBZ. Enjoy! 12:17 PM Nov 12th from TweetDeck
#sqlconn note to self - always RE-restore base "demo database" so that the last demo's indexes don't mess you up! (which I usually do...) :( 12:08 PM Nov 12th from TweetDeck
@SQLVariant Technically the first log file should never be removed/deleted. Ideally, it's appropriately sized and on fast drive/LUN. 3:52 PM Nov 11th from TweetDeck
@SQLVariant A better way get rid of large log would be to change to SIMPLE rec model. Run a checkpt. Use SHRINKFILE & alter to correct size. 3:52 PM Nov 11th from TweetDeck
@StaciaMisner #sqlconn LOL. I think he means more that people should chart it in some way. Not specific to pie charts. U need blog 4Y tho. 3:11 PM Nov 11th from TweetDeck in reply to StaciaMisner
@way0utwest #sqlconn Paul did logging in am. We always tell people NOT to delete the log file. Definitely NOT recommended by us! 3:10 PM Nov 11th from TweetDeck in reply to way0utwest
@way0utwest #sqlconn LOL. Yes, deleting the log file clears it and breaks the continuity of log chain. Bad Steve, bad. ;-) ;-) 2:58 PM Nov 11th from TweetDeck in reply to way0utwest
#sqlconn Except when continuity of log is broken. SQL will clear on chkpt & on 1st bu starts rec. Won't clear fwd. Now it's back to you. 2:57 PM Nov 11th from TweetDeck
#sqlconn The log is never cleared by any other type of backup (despite what it may look like ;-). 2:54 PM Nov 11th from TweetDeck
#sqlconn Nothing clears the tlog except tlog backups. If a full is running & a log bu occurs clearing is def until full completes. 2:53 PM Nov 11th from TweetDeck
#sqlconn This is why you cannot clear the log during a full backup. However, you CAN still do log backups (as of 2005+). 2:51 PM Nov 11th from TweetDeck
#sqlconn A full backup backs up all db pages. If tran writes to multiple pages, backup has some pages w & w/o change. Needs tlog 4 recovery. 2:50 PM Nov 11th from TweetDeck
@way0utwest I'm sorry! I suspect she was riding?? I hope it was a clean break and an easy recovery? Owwww!!! Give her our best!! 3:00 PM Nov 10th from TweetDeck in reply to way0utwest
@PhilBrammer One case would be if you have an OR clause and each of the arguments are selective enough to use the index(es). 2:59 PM Nov 10th from TweetDeck in reply to PhilBrammer
@PaulRandal And I'm married to you... I think we need a TSQL intervention! See what happens when I leave him alone to write TSQL ;-) ;-) 2:46 PM Nov 10th from TweetDeck in reply to PaulRandal
@shanselman I like to say "he is" as "his" but the meaning probably wouldn't be understood. ;-) 2:38 PM Nov 10th from TweetDeck in reply to shanselman