Results 1 to 3 of 3
  1. #1
    Join Date
    Apr 2009
    Posts
    2

    Unanswered: Why dump tran not allowed for data and log on same device

    What exactly is the reason why Sybase does not allow by design that dump transaction is not allowed for database with data and log segments on separate devices?

    I have been working on Sybase ASE on and off for a few years, but can't simply answer this question

  2. #2
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    1 The answer is stated in several places in the manuals, and I cannot be asked to type it out here, try the SAG and look for the section "encyclopedia of tasks" ... separating data and log devices. It may look like a Sybase limitation but it isn't. The requirement is a basic data processing issue, not a Sybase limitation; unlike other rdbms, Sybase just ensures that you are never in an unrecoverable position.

    2 The other way of handling it is (and the vast majority of new DBAs are in this category), that's just the way it is, if you want Sybase to be able to recover the database. So go forth and implement it.

    Ask a specific question after reading the manuals, I would be happy to help.
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  3. #3
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    The shortest way of explaining it is:
    • it is not "not allowed by design"
    • it is stupid by principle, to place data and log on the same logical volume/physical disk. You are supposed to know that from your IT qualifications or experience. If you lose the disk/LV you have lost both data & log
    • if the data & log were on separate disks/LVs, you can lose one or the other, and sybase will continue (you can bring the db to a logical checkpoint; bring it down gracefully; lose nothing except active ucommitted transactions; replace the disk; bring it up)
    • if data & log were mixed on the same disk/LV, you cannot do that
    • if sybase did not prevent it or warn you, you might go along fine for years, then one day your disk breaks, and sorry joe, you lost everything ... you need to go to last nights full db dump file. The whole days transactions are lost
    • so sybase, which up to 12.5.4 is obsessed with reliability, do not let you get into that place where you may be fooled:
    --- if you mix log & data, it won't let you dump tran (and think that because you can do it today, you can do it anytime, such as when the disk fails)
    --- which in effect, forces you to do the right thing for productions systems

    Now, if you place data & log on the same Sybase device, it is the same as above (read Sybase Device for Disk/LV); SYbase does not let you fool yourself into thinking it is recoverable ... plus:
    • what you have is a log of unspecified size: whatever the device size is minus the data content
    • the log and data PAGES are quite mixed up, interspersed, in the one DEVICE
    • if you lose the log, you lose log+data; if you lose data, you lose log+data
    • that means you are not, and you can not, manage the log
    • acceptable for Dev systems, not anywhere near Test, UAT, or Production.
    • in which case you can truncate, but not dump, the log

    That being said, nowadays most people mirror both data and log, so the recoverability requirement being discussed here is handled another way.

    That being said, it is still completely stupid to place data & log on the same disk/LV/Device. The log is th heaviest use device. The first item of performance is to place it on its own separate Device/Disk/LV, away from the data. If not for recoverability, then for load sharing.

    See, even the shortest explanation is long !
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •