debugMinor
Why does truncate table put inside a transaction fail with ASE error 226?
Viewed 0 times
whyerrorwithputasefail226truncatetransactiondoes
Problem
Spotted some answer excerpts on the question entitled "Why use both truncate and drop?":
"TRUNCATE is logged, and it can be rolled back.
...
Let me rebut these falsehoods. I am writing this rebuttal from a SQL Server perspective, but everything I say here should be equally applicable to Sybase." answered Nov 8 '11 at 21:39
Attempted to add comment but original post has been protected hence this new Question as a workaround.
The above may be true for Microsoft SQL Server, it is NOT for Sybase - see ASE error 226 below
Furthermore - I almost agree with the notion that truncate before drop should make no difference...
DROP TABLE on its own is marginally better as table page deallocation is not logged while truncate on its own seems to incur small amount of logging surprisingly.
SYSLOG Audit Trail : truncate on its own (as shown below - TX seq is based on the most recent 5 transaction being displayed)
```
Log Record Type Op TX seq
---------------------------------------- -- -----------
======>Checkpoint Record 17 5
Begin Xact 0 5
Delete Extent Log Record 77 5
Direct Update/In Place Update 9 5
Update Record for DOL Table 65 5
End Xact 30 5
======>Checkpoint Record
"TRUNCATE is logged, and it can be rolled back.
...
Let me rebut these falsehoods. I am writing this rebuttal from a SQL Server perspective, but everything I say here should be equally applicable to Sybase." answered Nov 8 '11 at 21:39
Attempted to add comment but original post has been protected hence this new Question as a workaround.
The above may be true for Microsoft SQL Server, it is NOT for Sybase - see ASE error 226 below
1> BEGIN TRAN
2> TRUNCATE TABLE xyz
3> go
Msg 226, Level 16, State 1:
Server 'ASE16', Line 2:
TRUNCATE TABLE command not allowed within multi-statement transaction.
1> ROLLBACK
2> goFurthermore - I almost agree with the notion that truncate before drop should make no difference...
- TRUNCATE TABLE on its own - involves some syslog activities (surprisingly)
- DROP TABLE on its own (without proceeding truncate)
- deallocate the table pages within an "empty" BEGIN/END Xacts pair
- updates sysobject, sysindexes system tables & their indexes & such internally generated DMLs involve logging within BEGIN/END Xacts pair
DROP TABLE on its own is marginally better as table page deallocation is not logged while truncate on its own seems to incur small amount of logging surprisingly.
SYSLOG Audit Trail : truncate on its own (as shown below - TX seq is based on the most recent 5 transaction being displayed)
```
Log Record Type Op TX seq
---------------------------------------- -- -----------
======>Checkpoint Record 17 5
Begin Xact 0 5
Delete Extent Log Record 77 5
Direct Update/In Place Update 9 5
Update Record for DOL Table 65 5
End Xact 30 5
======>Checkpoint Record
Solution
As previously mentioned in the question, I came across an old post entitled "Why use both truncate and drop?" while searching for Sybase ASE handling of
I noticed an extract in one of the answers which extrapolated, incorrectly, a Microsoft SQL Server feature (
I created a new question with a reference to the old one to clarify 2 points:
Point 1
-
In comparison,
-
IMPORTANT :
Point 2
truncate table with its special attributes different from other so-called minimally logged Sybase Transact-SQL (T-SQL) operations (e.g. select into). I noticed an extract in one of the answers which extrapolated, incorrectly, a Microsoft SQL Server feature (
truncate table being handled inside a transaction rendering this as logged & suitable for rollback) as equally applicable in Sybase ASE. I created a new question with a reference to the old one to clarify 2 points:
Point 1
- Unlike Microsoft SQL Server, one cannot put
truncate tableinside a transaction in Sybase ASE
- Doing so will hit ASE error 226 (see error text in the body of the Question)
- REASON :
truncate tabledoes not generate any log records pertaining to the removing of data rows instead data & index (if any) pages are simply deallocated, pages are marked unused
-
In comparison,
drop table updates system catalogs (sysobjects, sysindexes etc.) having taking care of the equivalent of truncate table in a tiny transaction log events (visible in the log record audit as an empty BEGIN Xact/END Xact bracket).-
IMPORTANT :
truncate table is unique in 2 respects- (A) it can be used in databases without their dboption "
select into/bulkcopy/pllsort" being enabled first (unlike otherminimally loggedT-SQLcommands)
- (B) it does not prevent subsequent
dump transactioncommand on the database (unlike otherminimally loggedT-SQLcommands - the workaround of this restriction is to take a full orcumulativeDB dump to reset it)
Point 2
- The original Question/Answer refer to whether truncating a table first before dumping it would make any gain in performance, elapsed time etc. The consensus appears to a NO answer.
- In Sybase ASE at least, while there is no significant efficiency gain to
truncate tablefirst, a closer examination of the transaction log activities seems to reveal a small log related overhead in executing thetruncate table(this is absent in the processing ofdrop tablewithout a proceedingtruncate tableas shown in the syslogs audit trails in the body of the Question).
Context
StackExchange Database Administrators Q#186154, answer score: 2
Revisions (0)
No revisions yet.