Well, in the first table, there are 390 pages, 84% have data that can be cleaned up (think pointers to indexes and data).
The second table only has about 7% with data to be cleaned up, which isn't low, but not particularly high either. I'm not so sure why you would have issues there.
I would suggest you try running a reorg rebuild on both tables, and then see how long the dbcc takes.
From your post, did not see any error with dbcc checkdb. So you do not need to fix any dbcc error.
For the fragmentation, you may run reorg rebuild to the 2 tables.
-- step 1 reorg rebuild with proper syntax
-- according to the menu online for ASE 12.5. reorg rebuild can be used only on data-only-locked tables.
-- sp_help mytab to find out lock schema
reorg rebuild mytab
go
-- step 2 dbcc checktable
select getdate()
go
dbcc checktable (mytab) -- check table not the entire db
go
select getdate()
go
mytab1: 390 pages (for 2k pagesize=780kb)
mytab2: 82265 pages (for 2k pagesize=165430kb)
mytab2 should take longer.
Regards,
To change the procedure for the LCT try using sp_modifythreshold.
While you cannot drop the LCT you can try to reset it (eg, in case it was corrupted/garbled at some point) via: select lct_admin('lastchance')
As for the other threshold being too close to an existing threshold, the thresholds need to be 2x @@thresh_hysteresis pages apart.
Just bind the table back to the default data cache.
-bret
One possible danger is that the script will not have finished running by the end of your maintenance window. REORG REBUILD will hold an exclusive table lock until it completes.
just to supplement Mark's post:
To get the LCT you can use as already mentioned lct_admin:
select lct_admin('lastchance', db_id)
The db_id you get for example from sp_helpdb.
If lct_admin(“lastchance”, dbid) returns zero, the log is not on a separate segment in this database, so no last-chance threshold exists.
Regards,
Jens
Hello Jens,
they are using ASE 12.5.x and don't have any SAP Application in use.
With kind regards
Stefan
Hello,
I'm still wondering why you want to rebuild all indexes. Why did you decide to do so ? Do you have frequently problems with the index access ? Did you changed something the sort order or similar ?
With kind regards
Stefan
We reorg or rebuild our indexes ever weekend but not on all tables - just those which slow a bit of fragmentation.
Reorging reduces the fragmentation of volatile tables, reduces space usage (which if you've got slow disks can be a major performance hit) and reduces volatile query plans. I'm also in the process of moving from running "update statistics" to "update all statistics" to further reduced bad query plans.
I don't think this is unusual, every place I've worked in the last 25 years does this.
Are there any places (with large data volumes or just a few tables) which don't ?
Hello Mike,
yes in this case this makes sense, in this care reorg rebuild is the best approach to do so. Depends what version of ASE you use, you can adjust the reorg with different parameters. Also some customers use datachange() to identify the tables that might need a reorg or update stats. Or MDA tables will help you to see how many forwared rows / wasted space you have.
I was wondering cause Kent said he would like to rebuild all indexes in his database.
Regards
Stefan
datachange() is ok but not really good enough to rely on its own. I agree MDA tables help as well.
But generally best to go for overkill and reorg/index rebuild as much as possible - if you've got a 24 hour window for maintenance - then do as much as you can in those 24 hours.
Personally I'd like something built into the server to do this for you. Since every location has a version of this might as well have it built it - and be a good feature to the more novice of DBA's
Hi
Recently I have faced with a strange problem. Developers of one of my customers came with a query like this:
SELECT *
FROM packages
WHERE packages.item_number = 427909 OR 427909 = 0
go
"packages" is a table, there is an index on item_number column and "packages.item_number = 427909" is a very much selective condition. However, adding of an apparently false condition "427909 = 0" causes the optimizer not to see the first condition at all, which results in an expensive table scan. The behavior is observed in both version 15.7 SP51 (via set option show_lio_costing) and 12.5.3 (dbcc traceon(302)). Removing of the apparently false condition solves the problem. My questions:
1. Is it an expected behavior? Why the optimizer stops seeing the first condition?
2. Is there any workaround that doesn't involve changing of a query? Developers will change the query, of course, but releasing of a new application version may take some time.
To illustrate the problem better, I pasted outputs of "set showplan on" and "set option show_lio_costing on" below.
Thanks in advance
Leonid Gvirtz
Beginning selection of qualifying indexes for table 'packages',
Estimating selectivity of index 'packages.idx_packages_item', indid 3
scan selectivity 1, filter selectivity 1
56533 rows, 330 pages
Data Row Cluster Ratio 0.2954172
Index Page Cluster Ratio 0.7847222
Data Page Cluster Ratio 0.2359819
using index prefetch (size 16K I/O)
Large IO selected: The number of leaf pages qualified is > MIN_PREFETCH pages
in index cache 'default data cache' (cacheid 0) with LRU replacement
using table prefetch (size 16K I/O)
Large IO selected: The number of leaf pages qualified is > MIN_PREFETCH pages
in data cache 'default data cache' (cacheid 0) with LRU replacement
Data Page LIO for 'idx_packages_item' on table 'packages' = 41797
Estimating selectivity for table 'packages'
Table scan cost is 56533 rows, 6651 pages,
The table (Datarows) has 56533 rows, 6651 pages,
Data Page Cluster Ratio 0.9943289
Search argument selectivity is 0.330035.
using table prefetch (size 16K I/O)
Large IO selected: The number of leaf pages qualified is > MIN_PREFETCH pages
in data cache 'default data cache' (cacheid 0) with LRU replacement
The Cost Summary for best global plan:
FINAL PLAN ( total cost = 52661.9 ):
lio=6976 pio=870 cpu=169599 tempdb=0
QUERY PLAN FOR STATEMENT 1 (at line 1).
Optimized using Serial Mode
STEP 1
The type of query is SELECT.
2 operator(s) under root
|ROOT:EMIT Operator (VA = 2)
|
| |RESTRICT Operator (VA = 1)(0)(0)(0)(7)(0)
| |
| | |SCAN Operator (VA = 0)
| | | FROM TABLE
| | | packages
| | | Table Scan.
| | | Forward Scan.
| | | Positioning at start of table.
| | | Using I/O Size 16 Kbytes for data pages.
| | | With LRU Buffer Replacement Strategy for data pages.
Looks very odd...
What's the index idx_packages_item ?
It seems to think a scan of this index is expensive
Data Page LIO for 'idx_packages_item' on table 'packages' = 41797
Is item_number unique ?
I've tried it on a table and don't get the same results.
Perhaps worth looking at "sp_options show" ?
Hi Mike
I have just succeeded to reproduce the problem on another customer site on ASE 15.7 SP60. See the output of "sp_options show" attached. You mentioned that you receive different results in your tests - could you share some details?
The index scan appears so expensive because the optimizer doesn't recognize the first condition and therefore assumes that a full index scan will be required, which is expensive. If I omit the second, always false condition then an index scan on item_number is used and the query returns very fast (4 LIO), as expected.
Also, if I replace the always false condition with another false condition related to the indexed column, such as " and packages.item_number = -1" (there are no such records for sure), then the optimizer recognizes both conditions, applies an OR optimization strategy and the query returns very fast.
Thanks
Leonid Gvirtz
What's the definition of the table ? And the number of rows.
Have you tried updating all the stats on the table (don't assume update statistics will work - I've had tables which required update all statistics)
See full reproduction of the problem attached, you can try the same on your environment. You can use a regular table instead the temporary one, the result will be the same. Statistics on the table are up-to-date.
My test looks like this (with and without the second condition):
select id, name into #sysobjects from sysobjects
go
create unique index idx1 on #sysobjects(id)
go
dbcc traceon(3604)
go
set statement_cache off
go
set showplan on
go
set statistics io on
go
set statistics plancost on
go
set option show_lio_costing on
go
select * from #sysobjects
where id = 7 or 7 = 0
go
set showplan off
go
set option show_lio_costing off
go
set statistics io off
go
set statistics plancost off
go
Thanks
Leonid Gvirtz
Very interesting - I agree the optimiser is .... less than optimal.
I haven't seen this but then those of us from the Sybase 10, 11 & 12 days generally avoid ORs ;-)
Hopefully SAP/Sybase will pick this up and improve the optimiser in the next release.
So smart solution. Thanks, Bret.
Hi
I have an ASE Cluster Edition 15.7 SP121 and in rare circumstances all the processes in the database been became in status sleeping. There is not errors in the Sybase ErrorLog. The Event ID for these process is 512 (waiting for buffer validation in cmcc_bufsearch) and 509 (waiting for buffer read in cmcc buf search). Additionally I need documentation about the possible events in Cluster Edition.
The solution until the moment has been Kill on dataserver because there is not posible kill the process or restart the server.
Anybody Can help me?.
dbcc memusage can cause problems on multi engine servers
how many engines do you have configured?
check: exec sp_configure "number of engines"
and which ASE version are you running?