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.
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.