This section includes error messages generated by the Adaptive Server kernel. They have text descriptions but no error numbers. These errors are displayed only in the Adaptive Server error log. They are presented in alphabetical order.
basis_daioconfig: Asynchronous I/O not available
This error (and/or additional errors starting with basis_daioconfig)
are raised when Adaptive Server is unable to boot up with asynchronous
I/O on an HP-UX system. This problem is caused by an incorrect
operating system configuration. Common reasons include:
The user starting the server belongs to a group which has inadequate shared memory locking privileges.
There is insufficient lockable shared memory.
System memory and swap space have become fragmented.
Asynchronous I/O is not available.
This writeup explains how you can investigate and correct the error, and provides additional resources for troubleshooting the memory problem.
Although they are reported in the Adaptive Server error log, basis_daioconfig errors
originate from the operating system and can be corrected with appropriate
management of memory parameters and device permissions.
Investigate the problem by checking for additional asynchronous
I/O related messages in the error log; these messages will
be printed just prior to the Asynchronous I/O
not available error.
An error such as
ioctl(ASYNC_CONFIG) failed: Not enough space
means that the operating system does not have enough shared lockable memory to allocate to asynchronous I/O buffers. Solutions vary, depending on the available resources and the type of tuning you choose. Options include:
Increase swap space. Ensure that the primary swap space is at least 1.5 times the amount of RAM.
Add more physical memory.
Reboot the machine. If the space problem is due to memory fragmentation, a reboot may solve the immediate problem (which will eventually reappear).
Reduce the server’s memory usage. If you have multiple ASE servers running on the machine, consider the usage of all such servers.
Set the kernel parameter SWAPMEM_ON to 0, increasing the amount of shared lockable memory available.
Examine the kernel parameter UNLOCKABLE_MEM. A value of 0 allows the operating system to dedicate 75% of physical memory to lockable memory. Consult the HP-UX documentation at http://www.hp.com for details.
An error like
ioctl(ASYNC_CONFIG) failed: Not owner
indicates a permission problem. Check that the file named /dev/async exists and is owned by user sybase, using the command:
ls -al /dev/async
It is also possible that the group (to which the user starting the server belongs) may not have permission to lock shared memory (MLOCK privilege). For details and instructions on setting the correct permissions, refer to TechNote 20380 in the Technical Library at http://www.sybase.com/detail?id=20380.
Consult the following for additional information about asynchronous I/O:
ASE Installation Guide for HP-UX. The "Pre-Installation Tasks" section contains information about enabling asynchronous I/O.
Permissions Information for Upgrading to ASE 11.5 or 11.9 for HP-UX Customers, in TechNote 20380 at http://www.sybase.com/detail?id=20380.
Release Bulletin Replication Server version 11.5.1 for HP9000/800 HP-UX. The "Special Installation Instructions" section describes how to enable asynchronous I/O for Replication Server.
Bufunhash: Buffer %lx from database '%.*s' has page number %ld in the page header and page number %ld in the buffer header. Buffer will be unhashed, no action is necessary. Printing headers for diagnostics:
This error may be caused by a hardware problem.
This error only appears in the error log, and it means that a cache management problem occurred. This can be a very serious error because it is often followed by database corruption, such as 605 errors.
Although often a result of hardware failure, this error can also be caused by operating system or Adaptive Server problems.
If possible, shut down and restart Adaptive Server immediately
after this error occurs. This may prevent the buffer cache error
from being flushed to disk.
Run complete diagnostics on the machine running Adaptive Server and on all disk drives and controllers attached to that machine.
Run complete dbcc checks, including dbcc checkalloc and dbcc checkdb, on any databases involved.
Repair or replace faulty hardware.
Shut down and restart Adaptive Server.
If you do not find any hardware problems, call Sybase Technical Support immediately.
Before calling Technical Support for assistance, have the following information available:
Server version and SWR version level
Server error log
Hardware error log
Text of all the error messages
Reproducible case (if possible)
Adaptive Server doesn't support use of character_set_name character set.
This error occurs when the client software default character set has not been installed on the Adaptive Server to which the client is trying to connect. This happens most often when the client is running on a different operating system from Adaptive Server.
To allow the client and Adaptive Server to communicate, do the following:
Determine whether the client software character set is installed on Adaptive Server by executing this query:
1> use master 2> go
1> select name, id, csid from syscharsets 2> go
If the client software's default character set appears in the output, have your primary site contact call Sybase Technical Support. If it does not appear, go to step 2.
If the client software's default character set does not appear in the output, you may be able to set the client software to the character set which Adaptive Server is using. For isql, you can do this with the -J flag. Refer to “Configuring Client/Server Character Set Conversions” in the System Administration Guide for details. If you cannot set the client software to the character set Adaptive Server is using, go to step 2.
WARNING! Familiarize yourself with all the instructions in the Adaptive Server installation and configuration guide before completing step 2, in order to make the character set addition a smooth process.
Run the installation utility sqlloc (or the equivalent for your platform). Choose the additional character set item from the character set menu. If the particular character set you need is not one of the options listed, you must purchase that character set by purchasing a Language Module from Sybase, and install it with sqlloc or its equivalent.
Try again to connect to Adaptive Server with the client software. Call Sybase Technical Support if you are still unable to connect to Adaptive Server.
kistartup: could not create shared memory
This error may be caused by a hardware problem.
kistartup is the Adaptive Server kernel initialization routine. It performs the following tasks:
Reads the configuration parameters
Allocates kernel tables and buffer pools
Sizes memory
Initializes devices
Spawns the service processes
Starts the scheduler.
When kistartup is unable to create shared memory for kernel initialization, the error “kistartup: could not create shared memory” is written to the Adaptive Server error log.
kistartup errors occur after os_create_region errors.
Refer to os_create_region Errors for information about recovering from the os_create_region errors which precede the kistartup error. Once those errors are corrected, the kistartup error will not occur.
Shared memory errors may be seen if you shut down Adaptive Server and restart it while Monitor Server is still active. You can correct this type of error by shutting down Monitor Server before restarting Adaptive Server.
The interaction between Adaptive Server and Monitor Server is covered fully in the Monitor Server User's Guide.
current process (0x%x) infected with %d
This error may be caused by a hardware problem.
Adaptive Server reports this error when it detects a UNIX signal specifying an error. The signal values (“%d”) displayed in the above message vary by platforms and Adaptive Server versions; the most common are either 10 or 11.
A value of 10 [SIGBUS] means that the operating system detected an address alignment error or a miscellaneous hardware error (for example, bus timeout).
A timeout can occur when the CPU issues a request across the bus for the contents of a memory location, and that request is not answered within that CPU's timeout period (usually a few nanoseconds).
A value of 11 [SIGSEGV] means that the operating system detected a segment violation error.
Sometimes this error occurs in conjunction with stack overflow or data corruption. For more information on stack overflow, refer to Stack Guardword Error.
The message appears in the Adaptive Server error log followed by a stack trace. The SQL causing error or the lasterror displayed in the Server error log may be the underlying cause for this error. But they can also be just the last data Adaptive Server had in its cache space.
In order to identify the lasterror (except in the cases where the lasterror is 0), get the number displayed by Adaptive Server in the lasterror field from the Adaptive Server error log and consult this manual for more information on this error number.
In the following example, the value for lasterror is 614.
00: 94/02/14 11:32:26.02 kernel: current process (0x1fb001d) infected with 11 00: 94/02/14 11:32:26.07 kernel: Address 0x808a6ef (closetable+0x2f7), siginfo (code, address) = (2, 0x30) 00: 94/02/14 11:32:26.07 kernel: ************************************ 00: 94/02/14 11:32:26.07 kernel: SQL causing error : CREATE TRIGGER 00: 94/02/14 11:32:26.07 kernel: curdb = 22 pstat = 0x10018 lasterror = 614
In order to correct this error, try to eliminate the lasterror first, as this might be one of the causes for this error (except when lasterror is 0).
Also, try rerunning the command referenced in the SQL causing error to see if the problem reoccurs.
If the process is infected with 11 and the problem can be reproduced, try and correct it as follows:
If the SQL causing error is a compiled object such as a stored procedure, trigger, or view, drop and recreate the object.
If the SQL causing error is ad hoc rather than a compiled object, moving the data may fix the problem. Use one of these options:
Select the table data into a new table, drop the old table, and rename the new table to the old table name.
Bulk copy the affected table out, drop and re-create the table, and bulk copy back in. This is the most efficient solution for a very large table.
If moving the data corrects the problem, the data may
have been corrupt. Be aware that moving corrupted data can lead
to a data loss.
Check your hardware error log as this error can be caused by hardware failure as well.
If this error occurs frequently, contact Sybase Technical Support. It would be useful to have a reproduction case (for example, a query which always causes the “infected” message) before calling Technical Support.
Before calling Technical Support for assistance, have the following available:
Server version and SWR version level
Server error log
Operating system error log
Text of all the error messages
Reproducible case (if possible)
dopen: open ’%s’, %s\n
A dopen error is raised when Adaptive Server is unable to complete an asynchronous or synchronous disk I/O operation on a unix platform. For example:
00:1999/12/26 22:59:10.97 kernel dopen: open ’/dev/vx/rdsk/db01076_m’, No such file or directory
dopen errors can occur during the Adaptive Server startup sequence, or during an engine startup. Depending on the nature of the problem, they may be accompanied by other messages such as dopen errors or numbered errors. A dopen error aborts the startup sequence.
Examine the server error log and note the exact dopen message text, the text immediately preceding and following the message, and any subsequent errors in the log. Corrective action depends on the type of problem encountered:
Make sure that the device, identified by the path shown in the message, exists and is correctly specified in your RUN_server file.
If the device no longer exists, you will need to restore from known, clean backups.
Check permissions on the directory or disk file shown in the message. Verify that the account starting the server has the appropriate permissions.
Since Adaptive Server reports this error when its I/O operation does not get a successful return value, this type of dopen error can be an early warning of disk problems. Examine the availability and condition of the device using your standard operating system procedures.
If you use mirroring, a kdconfig error following a dopen I/O error may indicate a mirror problem. For example:
00:99/05/26 16:05:29.64 kernel kdconfig: opening secondary master device 00:99/05/26 16:05:29.65 kernel dopen: open ’’, No such file or directory 00:99/05/26 16:05:29.65 kernel kdconfig: unable to read secondary master device
Refer to udunmirror Errors in this manual for information about resolving mirror problems.
Have the following information ready when you call Sybase Technical Support:
Adaptive Server version and SWR rollup level
Server error log
Operating System error log
RUN_server file
All versions
kernel: dstartio: I/O request repeatedly delayed; block number: %ld, vdn: %ld
This error may be caused by a hardware problem.
This error message is not dangerous and there is no data corruption connected with it unless it is reported together with other kernel messages in the error log which indicate corruption.
If this is an error message, it is a sign of inconsistencies or corruption relating to the asynchronous I/O capabilities of Adaptive Server. In this case, the above error message will be reported along with other error messages in the Adaptive Server error log.
If this message is accompanied by other error or kernel messages in the Adaptive Server error log, refer to the appropriate section of this manual (by error number or name) for corrective measures regarding those other messages.
This can be an informational message (occurring by itself, any number of times). If this is a warning message, it is displayed by itself in the Adaptive Server error log. In this case, the message is displayed in the Adaptive Server error log when:
Adaptive Server is configured for a different rate of concurrent asynchronous I/O requests than the operating system is configured for. Every time an I/O request has to be requeued in Adaptive Server's I/O queues, there is a decrease in overall performance due to requeueing overhead.
Adaptive Server is configured for a lower throughput rate of concurrent asynchronous I/O than it is capable of.
Asynchronous disk I/O allows Adaptive Server to initiate a disk operation to continue processing other data while the disk operation is completed. This can improve performance and recoverability especially when the master device, the user databases, and transaction logs are on raw disk partitions. For more information on raw disk partitions, refer to “Device Administration Issues” in the Encyclopedia of Tasks chapter.
The following I/O-related Adaptive Server configuration parameters and operating system parameters play a role when this error occurs:
disk i/o structures – the initial number of block I/O structures at Adaptive Server startup. This is an Adaptive Server configuration parameter.
max async i/os per server – the number of asynchronous I/O requests outstanding at one time for Adaptive Server. This Adaptive Server configuration parameter applies only to multiprocessor machines.
max async i/os per engine – the number of asynchronous I/O requests outstanding at one time for one engine (in the case of multiprocessor machines) and the maximum number of asynchronous I/O requests outstanding at one time for Adaptive Server (in the case of single processor machines). This is an Adaptive Server configuration parameter.
Asynchronous I/O operating system parameters.
Determine the current I/O-related Adaptive Server configuration parameter settings by running the following commands:
1> sp_configure "disk i/o structures" 2> go
1> sp_configure "max async i/os per engine" 2> go
1> sp_configure "max async i/os per server" 2> go
Use the instructions in the sections below to determine appropriate values and then use sp_configure to change the values of disk i/o structures, max async i/os per server, and max async i/os per engine. In general:
set max async i/os per server to a value less than or equal to the total allowable I/O count for the system on which the server is running.
set max async i/os per engine to a value less than or equal to max async i/os per server.
Check the UNIX kernel /usr/share/sys/sys/asynch.h file and record the value of the kernel parameter MAXASYNCHIO (maximum rate of concurrent asynchronous I/O requests, usually equal to 200 or more).
Check the values of the I/O-related Sybase configuration parameters and adjust them while Adaptive Server is shut down in order to match the value of MAXASYNCHIO.
If you are running on SunOS 4.1.3 (Sun Solaris 1.x), the UNIX kernel parameter perproc_maxasyncio (per-process limit on concurrent asynchronous I/O, found in /usr/share/sys/conf.common/param.c) defaults to 50. Increase this parameter to 200, to match the value of the Adaptive Server configuration parameter max async i/os per server. Rebuild the UNIX kernel after making the change to the UNIX kernel parameter.
The above recommendations are made to help you clear the error message. For asynchronous I/O tuning, contact your hardware vendor to find out what are the operating system parameters that improve asynchronous I/O performance on your platform.
On older versions (prior to Solaris 2.4), check whether there is a hard-coded value for MAXASYNCHIO (usually set to 200 and stored in /usr/include/sys/asynch.h or in /etc/system). If there is a hard-coded value for MAXASYNCHIO, set the values for Adaptive Server's asynchronous I/O configuration parameters to match the value of MAXASYNCHIO.
As of Solaris 2.4, MAXASYNCHIO is not configurable. Adaptive Server's asynchronous I/O configuration parameters should not be set higher than 200.
Configure the operating system for a higher number of outstanding asynchronous I/Os using smit. Bring up the smit aio screen by typing smit aio at the AIX prompt. Then, go to the “Change/Show Characteristics of Asynchronous I/O” screen and raise the “maximum number of REQUESTS” parameter to 4096.
This change will improve Adaptive Server performance. You will not need to reboot the operating system for the change to take effect. For more information on asynchronous I/O, search for “asynchronous” using the info utility.
Also, raise the values of the Adaptive Server I/O-related configuration parameters to 4096 to match the “maximum number of REQUESTS” value in smit.
In Digital UNIX releases before 3.0 (Digital OSF), the number of outstanding asynchronous I/Os was hard-coded in the operating system kernel in the AIO_MAX parameter (stored in a header file in /sys). Its default value was 64. For those releases, the Adaptive Server I/O-related configuration parameters should be set to 64 so that Adaptive Server can match the operating system's rate of concurrent I/O requests.
In 3.0 and later releases, you can change the number of outstanding kernel asynchronous I/Os. Refer to the Adaptive Server installation and configuration guides for details.
Also, raise the values of the Adaptive Server I/O-related configuration parameters to match the value of the kernel's maximum outstanding asynchronous I/O requests.
Depending on the operating system kernel, the maximum number of outstanding asynchronous I/O requests can be either 50 (on older HP-UX 8.x kernels) or 500 (on patched HP-UX 8.x kernels and default on HP-UX on 9.x kernels). this value is stored in the MAX_CONCURRENT parameter in /usr/include/sio/asynch. Adjust Adaptive Server's I/O-related configuration parameters to match MAX_CONCURRENT.
The error log example below shows the Adaptive Server start-up messages associated with the older 8.x asynchronous I/O driver and its limit of 50 asynchronous requests at one time. Once a later asynchronous patch has been applied or the new operating system version has been installed, this limit is increased to 500.
00: 92/06/04 14:38:07.10 server: Number of blocks left for proc headers: 351. 00: 92/06/04 14:38:07.36 kernel: basis_dioinit: Using older version of asynch I/O driver with 50 concurrent requests 00: 92/06/04 14:38:07.38 server: Opening Master database...
For other operating systems, check your operating system manuals for information about asynchronous configuration issues.
If problems persist, refer to the error documentation in this manual or contact Sybase Technical Support.
Refer to:
“raw partition” in the Adaptive Server installation and configuration guides.
“Device Administration Issues” in the Encyclopedia of Tasks chapter of this manual.
Your operating system documentation on asynchronous I/O.
Have the following information ready when you call Technical Support:
Output from sp_configure for I/O-related parameters or listing of your configuration file
Server version and SWR version level
Server error log
Operating system error log
Text of all the error messages
kdopen: failed to open device %s for vdn %d
This error may be caused by a hardware problem.
Before using a database device, Adaptive Server attempts to perform some initialization tasks. When mirroring is being used, if Adaptive Server is unable to open the secondary side of a mirrored device for these initialization tasks, the message “kdopen: failed to open device %s for vdn %d” is written to the error log. %s is the physical path to the secondary side of the mirrored device and %d is the virtual disk number of the device.
This error can be raised for the following reasons:
A database device is offline.
A database device has been removed or renamed.
A database file or device is inaccessible to Adaptive Server for any other reason such as insufficient permissions.
Examine the Adaptive Server error log for other messages that may explain why this error has occurred. Refer to the instructions in this manual for resolving other errors associated with this error.
Identify the device involved in the error:
1> select name from master..sysdevices 2> where low/power(2,24) = vdevno
where vdevno is the virtual disk number of the device as shown in the error message.
Examine the availability and condition of the device involved using your standard operating system procedures and make sure the device is accessible.
basis_dlock: file '%s' already in use by a SQL Server
This error may be caused by a hardware problem.
During startup, Adaptive Server tries to lock the master device. If Adaptive Server finds that the master device is already locked, the message “basis_dlock: file '%s' already in use by an Adaptive Server” is written to the error log and Adaptive Server does not start. %s is the name of the master device file.
The most common reasons for this error are:
You are trying to start a server with a master device that is already being used by another Adaptive Server.
The Server you are trying to start is already running.
At the operating system level, check the processes that currently exist and determine whether an Adaptive Server using the master device you specified is already running.
If an Adaptive Server using the master device you specified is already running, and this is not the Server you want to start, determine the correct master device name for the Server you want to start.
If you cannot determine whether the master device is already in use, reboot the operating system.
If the master device resides on an operating system
file system, you can copy the file to another name, modify your
runserver file, and start Adaptive Server with that new file.
Physical memory on this machine may be too fragmented
This error may be caused by a hardware problem.
At startup, Adaptive Server allocates and initializes the memory needed for its structures and cache. This error occurs when Adaptive Server is not able to initialize memory needed for its structures and static cache.
The most common cause of this error is that the total memory required for the configurable parameters is more than the memory configured for Adaptive Server.
At the operating system level, check memory use.
On UNIX machines, there are several commands for checking memory use. Following are examples of two of these commands:
% /etc/pstat -s
44076k allocated + 8920k reserved =52996k used, 40960k available
% vmstat
procs memory page disk faults cpu r b w avm fre re at pi po fr de sr s0 d1 d2 d3 in sy cs us sy id 4 0 0 0 336 0 1 0 0 0 16 0 1 0 0 0 181 260 399 84 2 14
If processes other than Adaptive Server are leaving memory fragmented, rebooting the operating system may resolve this error.
If you still cannot start Adaptive Server, refer to “Adaptive Server Does Not Start After Altering Configuration”in the System Database Recovery chapter for instructions.
Start your Adaptive Server.
Once your Adaptive Server is running, use sp_configure either to reduce the value of the configurable parameters (such as number of user connections and number of locks) or to increase the value of the total memory configuration parameter. The total memory parameter controls the size of memory, in 2K units, that Adaptive Server allocates from the operating system.
Refer to the Adaptive Server Enterprise Performance and Tuning Guide and “Configuring Memory” in the System Administration Guide for information about memory-related configuration parameters.
Before calling Technical Support for assistance, have the following available:
Server version and SWR version level
Server error log
Text of all the error messages
Text of your configuration file or sp_configure output
memory usage in procedure headers does not match memory usage. count in pss (%d) for server process id %d.
A process is a task being carried out by Adaptive Server. Processes can be in various states such as running or waiting for resources. For each user process and some system processes, Adaptive Server maintains a Process Status Structure (PSS) to track the state of the process and its use of resources. It also maintains an array of structures in the procedure header, each of which represents a physical page of memory in procedure cache.
When a process completes, Adaptive Server performs cleanup tasks such as freeing up resources used by the task. This error is reported when Adaptive Server cleans up after normal completion of a batch process, and determines that the memory usage tracked by the procedure header does not match the usage total maintained in the PSS.
This error may be due to an Adaptive Server problem.
No action is required, since this is an informational message and does not result in any incorrect behavior. Upon detecting the memory count mismatch, Adaptive Server corrects the appropriate counter, completes the cleanup tasks, and continues processing.
Before calling Technical Support for assistance, have the following available:
Server version and SWR version level
Server error log
Text of all the error messages
11.5, 11.0.3.1 and earlier
Using '%s' for network information.
Adaptive Server uses information from the network addressing (interfaces) file located in the $SYBASE directory when it starts up and when it tries to establish a connection to a remote server. At those times, Adaptive Server displays this message, including the complete path of the interfaces file which was used.
Following are examples of this message for UNIX and OpenVMS:
kernel: Using '/usr/u/sybase/interfaces' for network information.
kernel: Using 'SYBASE_SYSTEM:[SYBASE]interfaces' for network information.
If a remote procedure call (RPC) is executed and no connection is currently established for that remote Server, Adaptive Server must first establish a connection to it, using a site handler process, before the RPC can be executed. Each time Adaptive Server establishes a site handler process, this informational message is written to the Server error log.
If the site handler process times out, then this message can occur many times for each remote Server. If the site handler for a remote Server does not time out, then Adaptive Server will write this message for the first RPC to that remote Server, and the message will occur only once for each remote Server.
Use sp_helpserver to check the status of the remote Adaptive Server. If the status column of the sp_helpserver output is “timeouts”, then you can use the following action to keep the network information message to one occurrence.
To limit this message to one occurrence for a remote Server, disable the “timeouts” option to that remote Adaptive Server. Log into isql as “sa” and use sp_serveroption to set the “timeouts” option to “no timeouts”:
1> sp_serveroption remote_sql_server_name, 2> timeouts, false 3> go
This will keep the connection to the remote Server established. It will be maintained until either the local or remote Server is shut down. If you have few available user connections, remember that one connection per remote Adaptive Server connection will be in constant use.
Refer to the Reference Manual for information about sp_serveroption.
uasetalarm: no more alarms available
The Transact-SQL command waitfor defines a specific time, time interval, or an event for the execution of a statement block, stored procedure, or transaction. Adaptive Server uses alarms to carry out waitfor commands correctly.
The number of alarms needed by Adaptive Server is related to the requirements of an application and the number of instances of that application being run simultaneously. The maximum number of alarms available for use by Adaptive Server is controlled by the number of alarms configuration parameter.
When Adaptive Server needs more than the number of alarms available, the message “uasetalarm: no more alarms available” is written to the error log.
Determine the current value of the configuration parameter number of alarms:
1> sp_configure "number of alarms" 2> go
Change the value of number of alarms to a value larger than the current value:
1> sp_configure "number of alarms", new_value 2> go
Shut down and restart Adaptive Server.
Each alarm structure uses 20 bytes of memory. If you
raise the value of number of alarms significantly,
readjust Adaptive Server's memory use accordingly.
server: Warning: OPEN OBJECTS parameter may be too low; attempt was made to free up descriptor in desfree(). Run sp_configure to increase parameter value.
or
server: Warning: OPEN OBJECTS or OPEN DATABASES parameter may be too low; attempt was made to free up descriptors in release_dbtable(). Run sp_configure to increase parameter value.
This message is a warning indicating that you do not have enough object descriptors or open databases available in the chain containing all the free descriptors.
This message is displayed in the Adaptive Server error log when Adaptive Server reaches the end of its array of allocated object descriptors, tries to recycle previously-used object descriptors and fails. It can also be displayed when Adaptive Server has fewer open databases configured than the number of databases on the Server.
To recover from this error, increase the values of the configuration parameters number of open objects and number of open databases.
The configuration parameter number of open databases sets the maximum number of databases that can exist at one time on Adaptive Server.
The configuration parameter number of open objects sets the maximum number of objects that can be open at one time on Adaptive Server.
Increasing the value for number of open databases or number of open objects does not have a significant impact on performance or storage requirements, but it does require some memory. For more information about how Adaptive Server allocates memory, refer to the Adaptive Server Enterprise Performance and Tuning Guide and “Configuring Memory” in the System Administration Guide.
Use the system procedure sp_configure to display the run values of the configuration parameters you need to change:
1> sp_configure "number of open databases" 2> go
If the value for number of open databases is less than the value displayed by select count (*) from sysdatabases, increase the value of number of open databases. Otherwise, increase the value of number of open objects only.
In Adaptive Server 11.5 and later , you can use sp_countmetadata to determine the current value of number of open objects and number of open databases. For example:
1> sp_countmetadata 'open objects' 2> go
There are 338 user objects in all database(s), requiring 165 Kbytes of memory. The 'open objects' configuration parameter is currently set to 500.
1> sp_countmetadata 'open databases' 2> go
There are 5 databases, requiring 189 Kbytes of memory. The 'open databases' configuration parameter is currently set to 12.
os_attach_region: shmat(%d): %s
This error may be caused by a hardware problem.
Adaptive Server uses the function os_attach_region to attach to a shared memory region based on a shared memory identifier. This error occurs when Adaptive Server fails to attach to a region. In this message, %d is the shared memory identifier and %s is an operating system error message.
The message “os_attach_region: shmat(%d): %s” is raised on UNIX systems only. Other operating systems raise slightly different errors.
An os_attach_region error can occur when the value of the operating system parameter shmseg is too small. For information about configuring shared memory properly, refer to the Adaptive Server installation and configuration guide.
This message can also be raised by Monitor Server. Refer to the Monitor Server User's Guide for details.
Refer to the operating system man pages for the shmat() system call.
os_create_region: shmget (0x%x): %s
os_create_region: Shared memory segment %d is in the way
os_create_region: uninitialized shared memory descriptor
os_create_region: shmat (%d): %s
os_create_region: can't allocate %d bytes
This error may be caused by a hardware problem.
Adaptive Server uses the following functions to manage shared memory:
os_get_shmid – create a shared memory identifier
os_create_region – create a region based on a shared memory identifier
os_attach_region – attach to a region based on a shared memory identifier
os_detach_region – detach from (and delete) the shared region
os_format_shmid – format a shared memory identifier for printing
When os_create_region errors occur, Adaptive Server will not start.
The message texts shown here apply to UNIX systems only. Other operating systems raise slightly different errors.
This message is written to the error log when Adaptive Server fails to get a shared memory segment. In this message, %x is a shared memory key based on the shared memory identifier and %s is an operating system error message.
This error follows the shmget message and is also written to the Adaptive Server error log. A value of -1 for %d means the region does not exist.
During creation of a shared memory region, Adaptive Server attempts to validate the descriptor for the memory region. This message is written to the error log if the descriptor is found to be invalid.
This message is written to the error log when Adaptive Server fails to attach at an address. In this message, %d is the shared memory identifier and %s is an operating system error message.
Adaptive Server was unable to allocate the number of bytes it requested for the shared memory region.
At the operating system level, check which shared memory processes are using and whether shared memory segments are being used by Adaptive Server.
To check this on UNIX, run this command as the “sybase” user:
% ipcs -m
IPC status from workstation1 as of Fri May 26 14:08:25 1995 T ID KEY MODE OWNER GROUP Shared Memory: m 256 0x699b7e24 --rw------- sybase sybase m 257 0x699b7e25 --rw------- sybase sybase
If shared memory segments are being used by Adaptive Server, reboot the operating system to clear shared memory or remove them using the ipcrm operating system command.
Before removing the shared memory segments, identify
the process that created them using the command “ipcs -ma” to
make sure you only remove the appropriate segments.
Check the $SYBASE directory to determine whether there are any *.krg or *.srg files left from an abnormal Adaptive Server exit. If any such files exist, delete them.
os_create_region errors can occur when shared memory is not configured properly on your operating system. For information about configuring shared memory properly, refer to the Adaptive Server installation and configuration guide for your platform.
Shared Memory Error on Digital Unix
os_create_region: can't allocate %d bytes indicates that one or more kernel parameters needs to be reset. Logically, resetting shm-max should allow Adaptive Server to configure shared memory. However, other operating system kernel parameters also affect allocation. Consult your operating system documentation for details.
Refer to the operating system man pages for the shget() and shmat() system calls.
Refer to the operating system man pages for ipcs and ipcrm.
kernel: write error on virtual disk %d, block %ld
or:
kernel: read error on virtual disk %d, block %ld
This error may be caused by a hardware problem.
This error occurs when Adaptive Server fails to read or write to the specified location on disk. This failure is usually a result of a physical disk problem.
If mirroring is enabled, you may also see the following errors:
udunmirror: i/o error on %s device ‘%s’
or
sddone: %s error on virtual device
Identify the device with the problem by selecting the row from sysdevices which has the virtual disk number indicated in the error message:
1> select name, phyname from master..sysdevices 2> where low/power(2,24) = virtual_disk_number 3> go
The output from this query should provide the physical name of the damaged disk. Shut down Adaptive Server and examine the disk as soon as feasible and correct any problems found to prevent further corruption. Then restart Adaptive Server.
The sp_diskblock procedure
described below also identifies the device.
Use the procedure described below to determine which database (if there is more than one database on the device), table, or index is affected by this error. Use this information to assess the potential severity of the problem quickly and decide on an action which is appropriate for your operating environment.
Use the sp_diskblock procedure supplied in “How to Gather Information About Read/Write Errors” in the Encyclopedia of Tasks chapter. The syntax of this procedure is:
sp_diskblock virtual_disk, block_number
For example, if the read/write error message displays a virtual disk number 4 and a block number 871, the procedure command is:
1> sp_diskblock 4, 871 2> go
Virtual disk 4, block 871 corresponds to: Logical page 1895 in the "production" database (dbid=4) on device "main".
Use the dbcc page command to determine which object is using that page. Refer to “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter for details on this procedure.
Refer to the writeups for dopen Errors and udunmirror Errors in this manual for information about dopen, sddone, and udunmirror errors.
server is unnamed
This informational message is displayed during Adaptive Server start-up if the Adaptive Server has not been given a name via the sp_addserver system procedure. The Adaptive Server name is stored in the sysservers system table as well as in the @@servername global variable. This name is used primarily for managing Server-to-Server communication and does not have to match the Server name used either in the interfaces file or in the runserver file.
No action is required for this informational message. However, the Adaptive Server administrator can prevent this message by assigning a name to the Adaptive Server via the sp_addserver procedure. Refer to the Reference Manual for information about restrictions on valid Adaptive Server names with sp_addserver.
To eliminate the message, assign a name to Adaptive Server using the sp_addserver command:
1> sp_addserver sql_server_name, local 2> go
The @@servername global variable will not reflect the name until Adaptive Server is restarted. All subsequent starts of the Adaptive Server display the new name during Adaptive Server start-up. For example, for an Adaptive Server named “MY_SERVER”, the message would be:
server: server name is 'MY_SERVER'
Although this Adaptive Server name is associated with Server-to-Server communication, specifying a name does not in itself allow this communication and therefore does not represent a security risk. Naming all Adaptive Servers in this way makes the Adaptive Server error logs easy to identify, because the Adaptive Server name is contained within the log.
*** Stack guardword corrupted.
This error occurs when the stack area used by an Adaptive Server process is corrupted. Adaptive Server usually shuts itself down after this error to avoid problems that could arise from this stack corruption.
WARNING! If this error occurs and Adaptive Server remains up, shut it down immediately!
At start-up, Adaptive Server allocates one stack area for every configured user connection. These stacks are in contiguous areas of memory, with a guard at the end of each stack. At the end of each stack guard area is a “guardword,” which is a 4-byte structure with a pattern. Adaptive Server periodically checks this pattern to determine whether it has changed. A change indicates that a process has overflowed its stack guard area. When this occurs, Adaptive Server prints the following messages in the error log and then shuts down:
kernel: *** Stack overflow detected: limit: 0x%lx sp: 0x%lx kernel: *** Stack guardword corrupted kernel: *** Stack corrupted, server aborting
In the first message, limit is the address of the end of the stack guard area, and sp is the current value of the stack pointer.
In addition, Adaptive Server periodically checks the stack pointer to determine whether it is completely outside both the stack and the stack guard area for the process. If it is, Adaptive Server shuts down, even if the stack guardword is not corrupted, and prints the following messages in the error log:
kernel: *** Stack overflow detected: limit: 0x%lx sp: 0x%lx kernel: *** Stack corrupted, server aborting
Stack corruption is usually the result of one process's stack overflowing its boundaries and writing on top of another process's stack. In general, an Adaptive Server process writes past the end of its stack area for one of two reasons:
The stack size is too small. The information placed on the stack is valid but its total size exceeds the specified stack size. This is often caused by a single, complex query which requires more than the average amount of stack space.
An incorrectly handled error results in recursive calls which eventually fill the stack, regardless of its size.
If this error occurs because a complex query has run out of stack area, correct the error by using one of the following methods :(choose solution 1, or choose between solutions 2 and 3 depending on your scenario):
Break up the query into smaller pieces, if possible.
Restart the server. Use the following information to select an appropriate size for the stack size configuration parameter:
The stack size should always be an even increment of 2K (2048 bytes). If a stack size is specified that is not divisible by 2K, Adaptive Server rounds it up to the next 2K increment.
Increase the stack size by no more than 2K at a time. If the stack size is too large, you may be unable to start Adaptive Server.
Increasing the stack size results in Adaptive Server requiring more memory for each configured user connection and device.
Use sp_configure to increase the stack size configuration parameter as follows:
1> sp_configure "stack size", new_value 2> go
Once this change is made, shut down and restart Adaptive Server so that the change will take effect.
WARNING! If you increase the value of the stack size configuration parameter, you may need to adjust other memory-related parameters. Refer to the Performance and Tuning Guide and “Configuring Memory” in the System Administration Guide for details.
Restart the server.
Increase the stack size, following the instructions in Solution 2 above.
Increase the stack guard size by 2K. Use sp_configure to increase this parameter as follows:
1> sp_configure "stack guard size", new_value 2> go
Once this change is made, restart Adaptive Server so that the change will take affect.
Increasing the stack size results in Adaptive Server requiring more memory for each configured user connection and device. Therefore, increasing the stack size without increasing the memory parameter, will result in less total cache space for Adaptive Server and could affect performance.
Refer to “Setting Configuration Parameters” in the System Administration Guide for information about sp_configure and the stack configuration parameters.
nconnect: t_rcvconnect, %s
This error may be caused by a hardware problem.
This error occurs when an Adaptive Server using a TLI-based interface tries to establish a client connection and an operating system error message is returned. This can happen when Adaptive Server tries to execute an RPC on a Server that is not running (Adaptive Server, Open Server, or Backup Server).
When this error occurs, the connection is not established and the message “nconnect: t_rcvconnect, %s” is written to the error log. %s is the text of the operating system error that caused the failure.
This is not a serious error unless it occurs frequently.
Resolve the problem that caused the operating system error contained in the Adaptive Server error message. You may need assistance from an operating system or network administrator. Refer to the operating system man pages for information about the t_rcvconnect() system call.
Check the Adaptive Server error log. If other errors exist, refer to the writeups in this manual for information about recovering from them.
If, after resolving the operating system problem and the problems found in the error log, you still get the message “nconnect: t_rcvconnect, %s,” call Sybase Technical Support.
Before calling Technical Support, have the following information available:
Server version and SWR version level
Server error log
Operating system error log
sp_helpserver and sp_configure output
Contents of interfaces file
udunmirror: i/o error on primary device '%s' udunmirror: i/o error on secondary device '%s' udunmirror: failing over to '%s'
This error occurs when Adaptive Server detects an I/O error on the primary or secondary device of a mirrored pair of devices. It is usually a result of a physical disk problem.
If an I/O error is detected on the primary device, Adaptive Server disables mirroring. sysdevices reflects information for the device as if a disk unmirror with side = primary and mode = retain was issued. Adaptive Server does this automatically and writes kernel messages like the following to the error log:
kernel: udunmirror: i/o error on primary device 'primary_device' kernel: DataServer i/o to the device will be disabled kernel: udunmirror: failing over to 'secondary_device''
If an I/O error is detected on the secondary device, Adaptive Server disables mirroring and sysdevices reflects information for the device as if a disk unmirror with side = secondary and mode = retain was issued. Adaptive Server does this automatically and writes kernel messages like the following to the error log:
kernel: udunmirror: i/o error on secondary device '/usr/u/sybase/test.mir' kernel: DataServer i/o to the device will be disabled
Using your operating system procedures, determine whether the device is damaged. If it is damaged, repair or replace it.
If the device is not damaged but it was unavailable for some other reason, make it available again.
If you use operating system files for Sybase devices or if the name of the device was changed, drop the mirror and re-create it:
1> disk unmirror name="device_name",
2> side={primary|secondary}, mode=remove
3> go
1> disk mirror name="device_name", 2> mirror="full_mirror_name" 3> go
where side is the device that was temporarily disabled.
On a UNIX system, you can also use the operating system
command touch to create the file and then issue
a disk remirror command.
If you did not need to drop and re-create the mirror, use the disk remirror command to make the device accessible to Adaptive Server:
1> disk remirror name = "device_name" 2> go
You can use the disk remirror command
if Adaptive Server automatically disabled mirroring or if you issued
a disk unmirror with mode = retain command.
If you issued a disk unmirror with mode = remove command,
you can only reinstate disk mirroring by issuing the disk
mirror command.
Refer to the Reference Manual for information about the disk mirror, disk remirror, and disk unmirror commands.
ueoffline: No more engines can be offlined in order to support %d outstanding network connections. Please try later when the server has fewer connections.
As of Version 12.0, Adaptive Server allows SAs to bring down server engines by using the dbcc engine(offline) command. Along with the existing dbcc engine(online) command, this makes it possible for SAs to dynamically optimize the number of engines on a server based on the work load.
When you execute dbcc engine(offline), Adaptive Server checks whether the remaining engines can accommodate the outstanding user connections. This error is raised if taking down the engine would make it impossible to support the current connections to the server.
Wait until there are fewer active connections, then re-try the dbcc engine(offline) command.
Use sp_who periodically to determine the number of active user connections on your server. Use the following command to determine the upper limit on the number of file descriptors available for server connections:
1> select @@max_connections 2> go
The return value represents the maximum possible descriptors available. Take into account overhead such as site handler connections, and note that overhead increases with the number of engines.
12.0 and later
