Post reply

Concurrent Operations

  • December 15, 2011 at 8:49 am

    #1422007

    Thanks Steve

  • December 15, 2011 at 10:20 am

    #1422095

    Hugo Kornelis (12/15/2011)

    If you really want to test the statement made in today's question, you have to run the two backup commands from two seperate tabs in SSMS

    Out of curiosity (I guessed wrong :crying:) I did a test using WAITFOR,SELECT GETDATE();BACKUP;SELECT GETDATE() in two separate SSMS query windows

    both started at the same time, completing without error and taking 0.58 secs, one finished after 0.58 secs from start the other after 1.2 secs

    Far away is close at hand in the images of elsewhere.
    Anon.

  • December 15, 2011 at 3:06 pm

    #1422245

    David Burrows (12/15/2011)

    Hugo Kornelis (12/15/2011)

    If you really want to test the statement made in today's question, you have to run the two backup commands from two seperate tabs in SSMS

    Out of curiosity (I guessed wrong :crying:) I did a test using WAITFOR,SELECT GETDATE();BACKUP;SELECT GETDATE() in two separate SSMS query windows

    both started at the same time, completing without error and taking 0.58 secs, one finished after 0.58 secs from start the other after 1.2 secs

    I did a similar test. In my case, both backup statements claimed an execution time of approximately 3 seconds, but SSMS told me that one of the two windows had an actual execution time of 6 seconds. And because I had sp_who2 ready to submit in a third tab, I was also able to see the second process waiting for the first. (I did not run sp_lock, so I don't know what kinds of locks are involved in this case).

    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • December 15, 2011 at 3:08 pm

    #1422246

    I sometimes like questions where I have to guess what they mean, but sometimes I don't. Here I didn't, even though I eventualy got it right.

    These were the questions that had to be answered: did whoever wrote the question mean both backups to be of the same database? If so he was maybe sloppy because he didn't say so, so was he misusing "concurrent" to include one working while the other was queued waiting for it to finish?

    But not a bad question, I guess. People who read the explanation can learn from it. I for one have learnt from it. I was unaware of the BoL page referenced and I only got this question right because I had misunderstood the concurrency section of the backup page as saying that neither backup database nor backup log could be concurrent with backup filegroup - but this reference shows that backup log can be concurrent with backup file group, so this question has disabused me of a belief I've held for years (since I first started evaluating SQL 2008).

    Tom

  • December 15, 2011 at 10:58 pm

    #1422302

    Good Question Steve.

  • December 16, 2011 at 3:45 am

    #1422367

    good question!!

    thanks Steve

    [font="Times New Roman"]rfr.ferrari[/font]
    DBA - SQL Server 2008
    MCITP | MCTS

    remember is live or suffer twice!
    the period you fastest growing is the most difficult period of your life!

  • December 20, 2011 at 5:37 am

    #1423572

    Good question, thanks.

    http://brittcluff.blogspot.com/

  • December 21, 2011 at 10:57 pm

    #1424576

    Hugo Kornelis (12/15/2011)

    I did not run sp_lock, so I don't know what kinds of locks are involved in this case.

    spid = 58

    dbid = 7

    ObjId = 0

    IndId = 0

    Type = DB

    Resource = [BULKOP_BACKUP_DB]

    Mode = U

    Status = WAIT

  • August 2, 2012 at 8:33 am

    #1520878

    it was obvious for me

    What you don't know won't hurt you but what you know will make you plan to know better

Viewing 9 posts - 16 through 23 (of 23 total)

You must be logged in to reply to this topic. Login to reply