----------------------------------------------------------------------------
SYBASE TECHNICAL NEWS
Volume 6, Number 9 December 1997
----------------------------------------------------------------------------
Introduction
This issue of Sybase Technical News contains new information about your
Sybase software. This newsletter is intended for Sybase customers. All
issues of Sybase Technical News are included on the Technical Information
Library web pages.
Sybase Inc. Integrates Support Websites
You asked Sybase for a direct, free website for Sybase and Powersoft brands
support. Based on your input, Sybase now offers Sybase Inc. Support at
http://support.sybase.com. Our redesigned site allows quick access to Sybase
and Powersoft brands support plans, electronic services, and hot support
topics. If you need technical documentation, you can search against the
Technical Information Library, Solved Cases, Product Manuals (SyBooks &
PowerBooks), and Newsgroups. You can even narrow your search to a product
and then search on descriptive words, error numbers, and so on.
As always, you can access Sybase Inc. Support from the Sybase homepage at
http://www.sybase.com.
REMINDER: Sybase Ends Support for pre-11 SQL Server
Sybase support for Sybase SQL Server 10.x and 4.x ends in the Americas and
Asia/Pacific as of 1 January 1998. Support ends later in 1998 for Sybase
customers in Europe and Japan. For more information on end of support
status, and help with migrating to Sybase SQL Server 11.0.x or Adaptive
Server Enterprise 11.5, see our migration page,
http://www.sybase.com/migration or call Sybase Customer Support.
----------------------------------------------------------------------------
In This Issue
--------------------------------------
Tip of the Month
TechNotes:
* FAQs about Table Partitioning
http://techinfo.sybase.com/css/techinfo.nsf/DocId/ID=1271
* Using Parallel BCP to Reduce Partition Skew
http://techinfo.sybase.com/css/techinfo.nsf/DocId/ID=20092
* Year 2000 Compliance and the Sybase Database Server
http://techinfo.sybase.com/css/techinfo.nsf/DocId/ID=20134
Other Useful Information
Subscription
----------------------------------------------------------------------------
Tip of the Month: How to List Server Reserved Words
--------------------------------------
To list all reserved words for Adaptive Server Enterprise or Sybase SQL
Server, log in to isql and run this query:
1> select name from spt_values where type = "W"
2> go
The spt_values table is a look-up table in the master database that stores
system values used by other server processes.
New reserved words for Adaptive Server 11.5 appear in the chapter "System
Changes in Release 11.5 " in "What's New in Adaptive Server Enterprise?"
Also see Migrating to Sybase Adaptive Server Enterprise 11.5 for new
reserved words in releases 10.x, 11.0.x and 11.5.
----------------------------------------------------------------------------
TechNotes
--------------------------------------
FAQs about Table Partitioning
Contents
The questions in this TechNote include:
* What is Table Partitioning?
* How Do I Choose Which Tables to Partition?
* How Does Partition Assignment Relate to Insert Transactions?
* Can I Run Any Transact_SQL Command on a Partitioned Table?
* Can Two Tasks Be Assigned to the Same Partition?
* Does Table Partitioning Require User-Defined Segments?
* Must I Use Multiple Devices to Take Advantage of Partitions?
* How Do I Create a Partitioned Table that Spans Multiple Devices?
* How Do I Take Advantage of Table Partitioning with 11.5 Parallel bcp
in?
* What about Parallel Query Processing?
What is Table Partitioning?
Table partitioning is a procedure that creates multiple page chains for a
single table. For the 11.5 release, worker processes, which are subtasks
that execute a query, simultaneously access these page chains.
The primary purpose of table partitioning is to improve performance. The
tables that you choose to partition depend on your performance issues and
goals for the queries on the tables.
For 11.0 and 11.0.x releases, partitioning:
* Provides multiple insertion points for a heap table.
* Potentially improves performance by making it possible to distribute a
table's I/O over multiple database devices.
As of 11.5 release, partitioning also does the following:
* Improves performance when the server is configured to perform parallel
query processing, because there can be one worker process per partition
in a partitioned based scan.
* Enhances the System 11 ability to run multiple bcp jobs against a
partitioned table by allowing you to control what partitions bcp copies
data into. Facilitates load balancing a table in parallel with bulk
copy.
For more information about:
* Parallelism related to partitioning, see "What about Parallel Query
Processing?"
* Parallel query processing, see the technote "FAQs about Parallel Query
Processing"
* The steps for partitioning tables and special procedures for difficult
situations, as well as details on maintaining balanced partitions, see
thePerformance and Tuning Guide
Multiple Insert Points
By default, the server stores a table's data in one double-linked set of
pages called a page chain . If the table does not have a clustered index,
the server makes all inserts to the table in the last page of the page
chain.
When a transaction inserts a row into a heap table, the server holds an
exclusive page lock on the last page while it inserts the row. If the
current last page becomes full, the server allocates and links a new last
page.
As multiple transactions attempt to insert data into the table at the same
time, performance problems can occur. Only one transaction at a time can
obtain an exclusive lock on the last page, so other concurrent inserts must
wait and execute in turn.
Partitioning a table creates multiple page chains (partitions) for the heap
table and, therefore, multiple last pages for insert operations. A
partitioned table has as many page chains and last pages as it has
partitions.
Reduced I/O Contention
Partitioning a table can improve I/O contention when the server writes
information in the cache to disk. If a table's segment spans several
physical disks, the server distributes the table's partitions across
fragments on those disks when you create the partitions.
A fragment is a piece of disk on which a particular database is assigned
space. Multiple fragments can sit on one disk or be spread across multiple
disks.
When the server flushes pages to disk and your fragments are spread across
different disks, I/Os assigned to different physical disks can occur in
parallel.
To improve I/O performance for partitioned tables, you must ensure that the
segment containing the partitioned table is composed of fragments spread
across multiple physical devices. For parallel queries, distributing
partitions across physical disks not only reduces I/O contention but also
speeds processing and achieves a higher level of parallelism.
Caveats Regarding I/O Contention
Be aware that when you use partitioning to balance I/O you run the risk of
disrupting load balancing even as you are trying to achieve it. The
following scenarios can keep you from gaining the load balancing benefits
you want:
* If you split a frequently updated table and its clustered index across
physical devices, the balance of disk allocation can change across time
unless you drop and re-create the table.
* Several heavily used tables and indexes are placed on a single physical
device in the default pool of space.
* Your fragments differ in size.
* Other objects are using the fragments to which the partitions are
assigned.
* A bcp job inserts many rows within a single transaction without the
batch option. Because a partition is assigned for the duration of a
non-batch bcp transaction, a huge amount of data could go to one
particular partition, thus filling up the fragment to which that
partition is assigned.
For more information about distributing data evenly, see the Performance and
Tuning Guide .
Can I Partition Any Table?
No. You cannot partition the following kinds of tables:
* Pre-11.5:
o Tables with clustered indexes.
o System tables.
o Work tables.
o Temporary tables.
o Tables that are already partitioned. You can unpartition and then
re-partition tables, however, to change the number of partitions.
* As of 11.5:
o System tables.
Work tables. Adaptive Server may partition work tables, but you
cannot directly partition them.
o Tables that are already partitioned. You can unpartition and then
re-partition tables, however, to change the number of partitions.
Text and Image Columns
You can partition tables that use text and image datatypes. The text and
image columns, however, are not partitioned; they remain on a single page
chain.
How Do I Choose Which Tables to Partition?
As of release 11.5, partitioning tables enables you to run parallel queries
on heap tables and tables with clustered indexes. For example, you can
partition heap tables that have large amounts of concurrent insert activity.
A heap table is a one with no clustered index, although it may have a
nonclustered index, such as:
* An "append-only" table to which every transaction must write.
* Tables that provide a history or audit list of activities.
* A new table into which you load data with bcp in .
For pre-11.5 systems, if you want to create a clustered index after
loading in data, first unpartition the table.
Can I Run Any Transact-SQL Command on a Partitioned Table?
No. Once you have partitioned a table, you cannot use any of the following
Transact-SQL commands on the table until you unpartition it:
* Pre-11.5:
o create clustered index
o drop table
o sp_placeobject
o truncate table
o alter table table_name partition n
* As of 11.5:
o sp_placeobject
o truncate table
o alter table table_name partition n
How Does Partition Assignment Relate to Insert Transactions?
A user is assigned to a partition for the duration of a transaction.
Assignment of partitions resumes with the first insert in a new transaction.
The user holds the lock, and therefore partition, until the transaction
ends.
For this reason, if you are inserting a great deal of data, you should batch
it into separate jobs, each within its own transaction. How Do I Take
Advantage of Table Partitioning with Parallel bcp in? provides more details.
Can Two Tasks Be Assigned to the Same Partition?
Yes. The server randomly assigns partitions. This means there is always a
chance that two users will vie for the same partition when attempting to
insert and one would lock the other out.
The more partitions a table has, the lower the probability of users trying
to write to the same partition at the same time.
Does Table Partitioning Require User-Defined Segments?
No. By design, each table is intrinsically assigned to one segment, called
the default segment. When a table is partitioned, any partitions on that
table are distributed among the devices assigned to the default segment.
In the example under How Do I Create a Partitioned Table that Spans Multiple
Devices? , the table sits on a user-defined segment that spans three
devices.
Must I Use Multiple Devices to Take Advantage of Partitions?
It depends on which type of performance improvement you want. For processing
in serial, the advantage is not that great. For parallel query processing
and parallel sort, however, partitioning noticeably improves performance.
Partitioning is, in fact, required for parallel sort such as index creation.
Table partitioning improves performance in two ways: primarily, by
decreasing page contention for inserts and, secondarily, by decreasing I/O
contention. What Is Table Partitioning? explains each in detail.
If you want to decrease page contention you do not need multiple devices. If
you want to decrease I/O contention, you must use multiple devices.
How Do I Create a Partitioned Table that Spans Multiple Devices?
Creating a partitioned table that spans multiple devices is a multi-step
procedure.
In this example, we assume the following:
* We want to create a new segment rather than using the default segment.
* We want to spread the partitioned table across three devices, data_dev1
, data_dev2 , and data_dev3 .
Here are the isql steps:
1. Define a segment:
1> sp_addsegment newsegment,
2> my_database, data_dev1
3> go
2. Extend the segment across all three devices:
1> sp_extendsegment newsegment,
2> my_database, data_dev2
3> go
1> sp_extendsegment newsegment,
2> my_database, data_dev3
3> go
3. Create the table on the segment:
1> create table my_table
2> (names, varchar(80) not null)
3> on newsegment
4> go
4. Partition the table:
1> alter table my_table partition 6
2> go
After completing these steps, you have 2 partitions on each device.
Remember, keeping the number of partitions relatively small requires less
resources (fewer worker processes).
How Do I Take Advantage of Table Partitioning with Parallel bcp in ?
Using parallel bcp to load data into a partitioned table enables you to put
the data in a specific partition. Adaptive Server 11.5 uses and is shipped
with bcp 11.1.1.
You can take advantage of table partitioning with parallel bcp...in by
following these guidelines:
1. Do the following preliminary tasks:
o Locate the table on the segment, and partition the table.
o Drop all indexes and drop triggers. This ensures fast,
minimally-logged bulk copying, instead of slow, completely logged
bulk copying.
o Set database option trunc log on chkpt , if you want to keep the
log from filling up during large loads.
2. Running simultaneous jobs increases throughput. Break up the data file
into multiple files and simultaneously run each of these files as a
separate bcp job against one table as follows:
o 11.5 : Specify the partition number for each bcp task as follows:
bcp table_name
..tab3:1 in filename
This syntax eliminates the risk of page lock contention.
o Pre-11.5 : Choose a number of partitions greater than the number
of bcp jobs. Having more partitions than processes (jobs)
decreases the probability of page lock contention. For 11.5,
however, this can impact parallel query performance.
o Use the batch option of bcp in to indicate more partitions than
jobs. For example, after every 100 rows, force a commit, using the
command:
bcp table_name
in filename
--b100
Each time the batch transaction commits, the server randomly
assigns a new partition for the next batch insert. This, in turn,
reduces the probability of page lock contention.
Note:Using the batch option --b N helps prevent a shortage of locks when
running many concurrent parallel bcp sessions. Another approach is to
increase the number of locks configuration parameter.
What about Parallel Query Processing?
In Adaptive Server Enterprise (ASE) 11.5, partitioning is the foundation of
parallel query processing. Data partitioning is extended to support
partitions on tables with clustered indexes. Partitioning adds a degree of
parallelism if your system is configured for parallel query processing,
which can give you notable performance gains. For details on partitioned
tables and parallelism, see the Performance and Tuning Guide under the
chapter on controlling physical data placement.
What are the Recommended Practices for Table Partitioning with Parallelism?
For optimal performance in parallel query processing:
Dedicate Space
Put partitions on dedicated segments on separate disk fragments on separate
physical devices with separate controllers.
Ensure Good Data Distribution
The steps to ensuring more even distribution of data are:
1. Drop the partitioned table's index.
2. Use parallel bcp to copy data into specified partitions. If you want to
create a clustered index at the end, be sure to bcp the rows in index
order.
3. Create the clustered index using the new Adaptive Server 11.5 create
clustered index command with the sorted_data option.
Alternatively, you can create a clustered index on a partitioned table. If
partition skew still prevents parallel processing, do steps 1-3. Before
creating the clustered index:
* Partition the table.
* Set number of worker processes and max parallel degree to at least the
number of partitions in the table plus 1.
* Execute sp_dboption "select into/bulkcopy/pllsort", true ; and run
checkpoint in the database.
Once you complete these preliminary tasks, use the create clustered index
command.
Re-partition Pre-11.5 Tables
Re-partition pre-11.5 tables that were partitioned. The upgrade process
initializes all partition ID fields in extent structures to 0 and
initializes partition statistics. Until re-partitioned, the tables do not
store partition IDs and do not have correct statistics. Without these IDs
updating partition statistics is much slower, and without good statistics
the optimizer cannot cost parallel query plans. The alter
table...unpartition and alter table...partition commands remove and create
partitions.
Monitor Partitioned Tables
Monitor partitioned tables for:
* Statistics accuracy . The optimizer uses statistics to choose the
optimal query plan. Regularly use the new update partition statistics
command to ensure accurate page counts on the table partition control
page; and use the update all statistics command to update the
distribution page for each index and the control page for each
partition.
* Partition skew . If the number of data pages in a table's partitions
differs significantly, parallel query performance can suffer. You can
run sp_help table_name to display information about a partitioned
table, including the ratio between average and maximum number of pages.
The ratio should be less than 2 for partition-based scans.
What do I Need to do to Create a Clustered Index on a Partitioned Table?
To create a clustered index on a partitioned table, Adaptive Server must be
configured for parallelism as follows:
* number of worker processes must be greater than or equal to the number
of partitions plus 1.
* max parallel degree and parallel_degree , if used, must be greater than
or equal to the number of partitions.
For details, see the System Administration Guide .
Additionally, number of sort buffers must be equal to or less than 90
percent of the number of buffers in the 2K pool area, before the wash
marker. For details, see the Performance and Tuning Guide .
You create a clustered index on a partitioned table with the create
clustered index command to redistribute the table data evenly over the
partitions. Depending on the index key ranges for each partition, the server
can distribute the rows equally within the partition.
You can only create a clustered index on a partitioned table in parallel.
Parallel index creation is a minimally logged task with these limitations:
* Before creating a clustered index, you must enable the pllsort database
option using sp_dboption . Otherwise, the task fails with Error 1565,
which reminds you to enable pllsort .
* After parallel index creation, to dump the transaction log of the
target database to a device you must first execute a complete database
dump.
* You cannot use create clustered index in the master database.
Note:Creating a clustered index requires about 120 percent of the space
that the table occupies, because the task copies data pages. For more
information about space planning for partitioned tables, see the
Performance and Tuning Guide .
How Can I Determine if a create index Command will be Executed in Parallel?
You can display the execution environment to be used for index creation by
running the set sort_resources on command. This is highly recommended early
in the process of physical database design to ensure efficient index
creation.
If the create index command can run in parallel, the sort_resources option
causes create index to display the two types of worker processes (producer
and consumer), output devices, sample records, and distribution elements. If
create index cannot run in parallel,the sort buffer size and number of
output devices are still displayed.
Creating an Index
Before index creation, turn sort_resources off. Unless the source table is
empty, create index does not work if sort_resources is on. For details on
using sort_resources , see the Performance and Tuning Guide .
If the number of worker processes varies between the sort_resources and
create index executions, the two execution environments may not match. You
can prevent the mismatch by executing the two commands close together or by
increasing the number of worker processes and maximum parallel degree.
Does Creating a Clustered Index Prevent Partition Skew?
Creating a clustered index on a partitioned table can result in balanced
partitions; that is, the data pages are evenly distributed among the table's
partitions.
In the first phase of index creation, the coordinating process reads a small
subset of rows from the source table to obtain a data sampling. Balancing
depends on how representative the sample is of the overall data set. A
non-representative sample produces invalid statistics which can result in
skewed data distribution.
The optimizer uses the distribution page during query plan index selection.
If a partitioned table is skewed, the distribution page of the index will
not be accurate. To update the index, run update statistics index_name .
Data in a partitioned table can become skewed if any of the following occur:
* The table was recently partitioned and all of the existing data pages
are in the first partition.
* A large number of rows are inserted into or deleted from a partition.
* A large number of rows are updated (not-in-place) in a partition.
* A large number of rows are bulk-copied into one or more partitions.
* Inserts are frequently rolled back.
To balance a partitioned table, try one of the following:
* Copy all of the data out, truncate the table, and use parallel bcp to
copy equal amounts of data into each partition.
* Alternatively, build a clustered index on the table. If this does not
balance the table, use the method described in the preceding bullet.
To verify that the attempt to re-balance partitions succeeded, run
sp_helptable .
Note:For help on how to handle balancing problems when devices are full,
see the Performance and Tuning Guide .
How Do I Check Data Distribution on a Partitioned Table?
You can use the following functions to evaluate how evenly data is
distributed:
* sp_help on a partitioned table gives detailed data about the table,
such as columns/types, indexes, and foreign keys, as well as partition
specific data.
* sp_helpartition shows only partition specific data, including the
number of data pages in each table's partition and a summary of data
distribution. Running this command also gives you a ratio of maximum to
average pages, which indicates whether a query can run in parallel. The
ratio must be less than 2 for the optimizer to choose a parallel plan.
sp_helppartition calls the ptn_data_pgs function, which prints the
number of pages in a specified table's partitions. You can run
ptn_data_pgs independently. For details, see the Performance and Tuning
Guide .
* sp_helpsegment lists the free pages for each device on the segment. The
number of data pages for a partitioned table on the devices can become
unbalanced, even though the number of data pages in a partition is
balanced. The imbalance is the result of extent stealing, which occurs
when partitions run out of space on the device and extents are
allocated on another physical device.
See the section on commands for partitioning tables in the Performance and
Tuning Guide .
How do Partitioning and Parallel Sorting Work Together?
Parallel sort requires at least 3 worker processes.
The following table shows the optimal number of worker processes needed for
various parallel sort commands, as well as how the server adjusts the number
when there are not enough worker processes. Producer refers to the worker
processes that read data from the input table and distribute it, and
consumer refers to the worker processes that read the data from a range of
the sort buffers and sort it into subindexes.
You ensure that the number of worker processes parameter is the total of the
two. For example, to create a nonclustered index, check whether the number
of worker processes is the sum of number of partitions on the table and the
number of devices on the target segment. If not, use sp_configure to change
the number.
Table 0-1: Number of worker processes needed
Command Producer Worker Processes Consumer Worker
Processes
Number of devices on
create nonclustered Number of partitions on target segment, if
index source, if available, or available, or adjust
1.
down to 2.
create clustered index Number of devices on
on unpartitioned table 1 target segment or adjust
down to 2.
create clustered index Number of partitions on Number of partitions on
on partitioned table source table, if source table only. Will
available, or 1. not adjust.
Number of partitions on
in work table created by Number of devices on
parallel query results, if tempdb, if available, or
available, or 1. adjust down to 2.
Number of devices on
in serial 1 tempdb, if available, or
adjust down to 2.
Note:The number of worker processes available is also determined by the
minimum values of the max parallel degree server-wide parameter and
parallel_degree session-wide parameter.
Using less than the optimal number of worker processes at runtime causes one
of the following results:
* The sort runs with an adjusted number of 3 processes or it runs in
serial, unless the session-wide parameter process_limit_action is set
to abort .
* For create clustered index on a partitioned table, the sort fails.
For more information about parallel sort, see the Performance and Tuning
Guide .
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Using Parallel BCP to Reduce Partition Skew
Background
Partition skew measures how balanced a partitioned table is with respect to
the distribution of data among the partitions. Over time, a table may take
on significant partition skew, and performance on the table may suffer.
With Adaptive Server Version 11.5, bcp allows you to specify partition
numbers when bulk copying new rows into a table. With an understanding of
the data distribution among partitions, you can use this capability to
reduce partition skew and re-balance the table.
Balancing a Table
To balance a partitioned table:
1. Determine the number of pages per partition.
2. Estimate the average number of rows per page in the table.
3. Determine how many rows to add to each partition.
4. Use bcp in with the appropriate range of rows.
Example
Consider an unbalanced table, mytab3, with three partitions. We need to load
40,000 new rows into mytab3. The steps to balance this table are as follows:
1. 1. Using the sp_helpartition procedure, you determine that the three
partitions contain 1000 pages, 150 pages, and 400 pages respectively.
2. Using
select count(*) from mytab3
to find the number of rows in the table, and knowing the total number
of pages, you estimate an average of 20 rows per page.
3. You use the following to determine the number of rows to add to each
partition (n denotes the n th partition):
Add(n) = (total existing rows + total new rows)/number of partitions -
Rows in the nth partition
For table mytab3:
Add(1) = (31,000 + 40,000)/ 3 - 20,000 = 3,666
Add(2) = (31,000 + 40,000)/ 3 - 3,000 = 20,666
Add(3) = (31,000 + 40,000)/ 3 - 8,000 = 15,666
4. Assuming all the new rows are in a single file named infile3, balance
the table by running the following three bcp jobs in order:
bcp -L 3666 mydb..mytab3:1 in infile3 &
bcp -F 3667 -L 24333 mydb..mytab3:2 in infile3 &
bcp -F 24334 mydb..mytab3:3 in infile3 &
Alternatives for Balancing a Table
Another way to use bcp to balance a table is to create separate input files,
each containing the appropriate number of rows for a partition. Each bcp
command uses a different infile; you do not need to specify first and last
row numbers.
To balance a table without adding any new rows, you can bcp out the table,
truncate it, and bcp in using one of the above approaches.
Additional Information
Details about sp_helpartition appear in the Sybase Adaptive Server
Enterprise Reference Manual .
Refer to your Sybase Adaptive Server Enterprise Utility Programs manual for
details about bcp .
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Year 2000 Compliance and the Sybase Database Server
Server Compliance Testing
Sybase has tested SQL Server 11.0.3 and Adaptive Server Enterprise 11.5 to
be sure that they conform to the year 2000 requirements. We have found only
a few problems during testing, which have been corrected in 11.0.3.2 and
11.5.1. For more information on compliance, go to the Web site
http://www.sybase.com/products and look under the heading Year 2000
Compliance.
This technote lists issues specifically related to the database server, and
does not include 72K status for Monitor Server, Historical Server, Monitor
Client Library API, Replication Server, and connectivity products. Other
Sybase products may have compliance issues. The product compliance matrix
has details at http://www.sybase.com/inc/corpinfo/year2000_matrix.html .
Also watch for updates to year 2000 information in the Technical Information
Library at http://techinfo.sybase.com/css/techinfo.nsf/Home .
The following database server products are year 2000 certified:
* SQL Server 11.0.3.2.
* Adaptive Server 11.5.1. The database server is 72K compliant as of
11.5.
Note:SQL Server was designed to handle the year 2000. SQL Server 4.9 and
10.x, however, will not be certified due to announced end-of-life
plans. There may be issues for these older releases, which you can
check on the problem report for your platform at
http://techinfo.sybase.com/css/techinfo.nsf/Problem+Reports .
Change Request Fixes
This section lists the upcoming change request (CR) fixes to support year
2000 compliance.
SQL Server 11.0.3.2
Release 11.0.3.2 fixes include:
CR Description
123843 Change error log to print 4-digit rather than 2-digit years.
Tape expiration does not work correctly when expiration passes the
133764 year 2000. Dumping to an existing tape that contains a dump prior to
2000 results in a "not expired" error.
In sybinit the date on the CONFIGURE SERVER PRODUCTS screen shows
137213 Feb 29 100 11:01 when run on February 29 2000. Log file also shows
year as 100.
137849 Add boot time trace flag 4048 to revert to 2-digit year in the error
log. This trace flag is required to run Replication Server Manager.
137992 is not applicable because auditinit does not ship with 11.0.3.2.
Adaptive Server 11.5.1
The release 11.5.1 fix is:
CR Description
137992 In auditinit the log file does not print the year properly when run
in the year 2000.
CRs already fixed in 11.5 are:
* 123843
* 133764
* 137849
137213 is not needed because sybinit does not ship with 11.5 and later
releases.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Other Useful Information
--------------------------------------
* SQL Server 11.x Bug Report
http://techinfo.sybase.com/css/techinfo.nsf/DocID/ID=2434
* Certification Reports
http://techinfo.sybase.com/css/techinfo.nsf/Certification
* Product Availability
http://techinfo.sybase.com/css/techinfo.nsf/New+Products
* End-of-Life/End-of-Support
http://techinfo.sybase.com/css/techinfo.nsf/Topic
* Error Messages
http://techinfo.sybase.com/css/techinfo.nsf/Topic
* Migrating to Sybase Adaptive Server Enterprise 11.5, a guide to help
you migrate from 4.x, 10.x and 11.0.x, including templates and
checklists.
http://techinfo.sybase.com/css/techinfo.nsf/DocID/ID=34982-01-1150-01
* What's New
http://techinfo.sybase.com/css/techinfo.nsf/Whats+New
For frequent updates, visit the Sybase Technical Information Library on the
World Wide Web at http://techinfo.sybase.com.
Electronic Case Management and Electronic Software Delivery access remains
limited to Sybase support contacts who are registered with SupportPlus
Online Services. ECM and ESD requires SSL web browser support. ECM and ESD
users also may access the Technical Information Library from behind the
firewall in the usual manner, allowing them to retain the security benefits
of using SSL with their web browser.
Subscription Information
--------------------------------------
Send comments to technews@sybase.com. To receive this document by regular
email, send email to majordomo@sybase.com, and in the body of your message
put subscribe inews-technews-full. For a summary version by email, put
subscribe inews-technews-summary. No subject line is necessary.
Staff
Betsy Brazy, editor
----------------------------------------------------------------------------
Contributors: Vinaye Misra, Karen Paulsell, Jenny Schaffer, Carol Talbeck
Disclaimer
--------------------------------------
No express or implied warranty is made by Sybase or its subsidiaries with
regard to any recommendations or information presented in Sybase Technical
News. Sybase and its subsidiaries hereby disclaim any and all such
warranties, including without limitation any implied warranty of
merchantability of fitness for a particular purpose. In no event will Sybase
or its subsidiaries be liable for damages of any kind resulting from use of
any recommendations or information provided herein, including without
limitation loss of profits, loss or inaccuracy of data, or indirect special
incidental or consequential damages. Each user assumes the entire risk of
acting on or utilizing any item herein including the entire cost of all
necessary remedies.
----------------------------------------------------------------------------
--------------------------------------------------
If you ever want to remove yourself from this mailing list, you can send
mail to "majordomo@sybase.com" with the following command in the body of
your email message:
unsubscribe inews-technews-full
If you ever want to add yourself from this mailing list, you can send
mail to "majordomo@sybase.com" with the following command in the body of
your email message:
subscribe inews-technews-full