Archive for January, 2010

Cleaning Shared Memory Segment and semaphore, for the ASE startup..

January 30th, 2010 2 comments

Panic dataserver, stopping it manually, and on restart showing issues with memory , meanwhile business people wants updates in every 5 mins…The situation is really worst for a DBA.

This posting is related to shared memory problem, for cleaning the shared memory:

When we shutdown the Sybase dataserver abruptly, by using the kill -9 or kill -12(or due to any reason automatically).

During the restart, sometime it gives the problem unable to create shared memory region, as below:

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): %

Killing Process may left behind the System V semaphore or shared memory left behind instead of being cleaned up automatically. To eliminate unneeded semaphores or shared memory segments, we need to release semaphore or shared memory segment manually.

For the Semaphores:

Run the command ipcs -sa, it will give all semaphores active in the UNIX box, look for the value “0” in the column NSEMS. 0 values indicate that unused semaphore, find all semaphore for the Sybase user and remove them using command ipcrm -s

testinghostname:(/sybase)=>ipcs -sa
IPC status from as of Thu Sep 17 08:50:11 EST 2007
s 201326671 0xc103d804 –ra-ra-ra- patrol dba patrol dba 2 8:45:15 0:00:08
s 201326668 0xc103d80e –ra-ra-ra- sybase dba sybase dba 0 8:50:08 0:00:00

testinghostname:(/sybase)=>ipcrm -s 201326668

For the Shared Memory:

To cleanup the Shared memory segment, which are assigned at OS level but not in use, run ipcs -ma command.

testinghostname:(/sybase)=>ipcs -ma
IPC status from as of Thu Sep 17 08:50:24 EST 2007
Shared Memory:
m 654311446 0x4103d80e –rw-rw-rw- patrol dba patrol dba 0 2304 1766 1766 8:50:18 8:50:18 0:00:08
m 671088657 0x4103d80d –rw-rw-rw- sybase dba sybase dba 0 1792 1766 1762 8:45:15 8:45:15 0:00:08
m 671088650 0x4103d80b –rw-rw-rw- root root root root 0 768 1766 1766 8:50:18 8:50:18 0:00:08
m 671088648 0x4103d80a –rw-rw-rw- sybase dba sybase dba 1 1280 1766 1766 8:50:18 8:50:18 0:00:08
m 654311548 0x4103d809 –rw-rw-rw- sybase dba sybase dba 0 256 1766 1766 8:50:08 8:50:08 0:00:08

Now look in the NATTCH field for 0, if it 0 zero for Sybase user , it is unneeded, but still assigned at OS level. Remove it ipcrm -m by providing the id.

testinghostname:(/sybase)=>ipcrm -m 671088657 -m 654311548

Now Start the dataserver….

Same case with backup server, if u get any error with shared memory..!


Source : Sybooks and UNIX Manuals on wwww.
Same Thread @

Sybase Delivers Best Quarter in Company History in 25 yrs!!!

January 28th, 2010 No comments


Very Good News for Sybase Folks!!!!

Sybase, Inc. Sybase reported record results for the quarter and full year ended Dec. 31, 2009. Among the company’s records were Q4 revenue of $331.7 million, annual revenue of $1.17 billion, and record operating margins and cash flow from operations. The company’s strong Q4 performance completes the best year in Sybase’s 25-year history.

Sybase Delivers Best Quarter in Company History, Resulting in Third Consecutive Year of Record Revenue!!


Source :
Same thread @

Categories: ASE, News Tags: , , ,

Sybase ASE 15.5 Meets Extreme Performance, Efficiency & Service Level Demands of Next-Generation Transaction Processing Systems

January 28th, 2010 No comments

Source : www &
New Version Includes In-Memory Database Option to Enable Data Virtualization in Cloud and Grid Environments

Sybase, Inc. (NYSE: SY), an industry leader in enterprise and mobile software, today announced the availability of Sybase® Adaptive Server® Enterprise (ASE) 15.5, the newest version of its high-performance, mission-critical enterprise database management system.

Sybase ASE 15.5 features the addition of two new options: ASE In-memory Databases (IMDB) and Advanced Backup Services. With these enhancements, ASE 15.5 continues to deliver unparalleled performance and manageability for data intensive environments that require very low response times and high throughput.

The IMDB option in Sybase ASE 15.5 enables data virtualization and scaling critical to meeting the needs of high data volume and high concurrent user organizations, whether deployed in public cloud or private data center environments. Unlike other in-memory products, the ASE 15.5 IMDB is fully integrated within ASE, eliminating the need for application changes and providing the flexibility that allows in-memory databases to be configured to meet application requirements.

“In-memory DBMS is an important dimension of the DBMS landscape, and will become more so in the coming years,” said Carl Olofson, Vice President of Research at IDC. “The Sybase developments that provide transparent in-memory database management show clear leadership in the DBMS field.”

ASE 15.5 also increases efficiency in the data center with the integration of the ASE Backup Server with Tivoli® Storage Manager (TSM) from IBM. With this support, ASE databases can be backed up on any TSM supported media, providing faster backups and restores with less network and storage resources required. This new integration provides a cost effective solution for storage management.

“The database management features offered by Sybase ASE 15.5 coupled with the storage management features offered by IBM® TSM provide a powerful solution to overcome the challenges of data protection faced in today’s business environment.” said Richard Vining, Product Marketing Manager, IBM Tivoli Storage. “We are pleased to provide Sybase ASE with the Ready for Tivoli software designation, which shows customers that the solution meets or exceeds IBM compatibility criteria and successfully integrates with one or more IBM Tivoli Software products.”

“In data centers, the IT challenge is to increase efficiency and availability while lowering data center costs. At the same time, application deployments in grid and cloud computing environments are increasing the requirements of transaction processing systems to support large volumes of concurrent users with high transaction rates,” said Brian Vink, vice-president, data management products, Sybase. “ASE 15.5 addresses these extreme requirements by delivering increased data throughput and greater concurrent activity while elevating productivity and uptime.”

Categories: ASE, News Tags: , ,

How to check the Replication Latency manually?

January 23rd, 2010 No comments

Hi Folks,
For the checking latency between Primary and Replicated DBs , we have several methods.

Here, I am posting the manual method for checking the replication latency. If you have any more thoughts, please comment it out.

Rite Now I am travelling to Delhi, my train got late, so I am spending my time with my fav, with new posting in blog.

For calculating the latency, we can make two tables in PDB and RDB with column as defaut datetime, and setup replication between these two tables.

Before excuting the batch of your’s queries, insert the id (only for reference for the point, where we executed the insert statement) and it will update the primary_datetime by default current system date.

After the completing the batch, insert the the next id, automaticaly it will get the finish date in default column.

Now go to RDS and check the diff between primary_datetime and replicate_datetime.

1. IN PDS/PDB Create one table as
create table timer_table(id int, primary_datetime datetime default getdate())

2. In RDS/RDB create same table with one extra coloum
create table timer_table(id int,primary_datetime datetime,replicate_datetime default getdate())

3. Setup the replication between both.

4. Before executing the batch insert the value in table as
insert into timer_table (id) values(100)

5. Execute your batch for queries.

6. After completion, execute the insert statement as
insert into timer_table (id) values(101)

7. Now go in the replicated dataserver(RDS/RDB) and check the diff between primary_datetime and replicate_datetime.
select datediff(ss,min(primary_datetime),max(replicate_datetime)) from timer_table

With the help of id you can check the latency upto that point. Even,You can customize this method for checking the latency.

Source : www & sybooks.
Same Thread @ :

Sybase India Names Inflow Technologies As National Distributor

January 18th, 2010 No comments

Sybase Software (India) Pvt. Ltd, the Indian subsidiary of Sybase, Inc., a provider of enterprise infrastructure and mobile software, today announced that it entered into a master reseller agreement with Inflow Technologies Pvt. Ltd in India.

The agreement will enable Inflow Technologies to extend the benefits of Sybase’s offerings, particularly analytics and enterprise mobility, to the growing market in India, said a press release.

Inflow Technologies, part of the US$ 5 billion Datatec Group, has presence in more than 12 locations across India and Sri Lanka.
Sources : news, www.

Basic Working of Sybase Replication Server

January 16th, 2010 No comments

Hey Guys,

Its my first post of New Year 2010. I am trying to put the basic understanding of Replication Server and whys it needs more monitoring. Hoping you will enjoy it!

Wishing you great new year 2010 ahead !

Basic Working of Replication Server

PDS : Primary Data Server
PDB : Primary Data Base

RDS : Replicated Data Server
RDB : Replicated Data Base

PRS : Primary Replication Server
RRS : Replicated Replication Server

RSSD : Replication System Database

1. RepAgent reads the record from transation log of the PDB for the tables which are marked for replication.

2. Logs into the PRS and write transactions in inbound queue of PDB in stable device.

3. Holds Data in inbound queue , untill it recieves commit.

4. Uses subscription information in its RSSD to decide what to do with the each transaction, after the commit:

i Discards the rans if there is no subscription.
ii Writes the transaction to the out bound queue if there are subscription.

5. Writes commited trans only in outbound queue according to subscription.

6. Sends transactions to their destination, it depends upone two things

i) if Replicated Database is managed by PRS
Apply changes to RDB using the DSI thread our the connection.

ii) If their are two server, RRS is managing RDB
Send commited trans to RRS over route.
RRS apply that changes in RDB

7. If apropriate, uses function string information in RSSD to compose command to submit to replicate database.

Source : sybooks and www.

As you people are seeing, there are lot of movement of trans/record , and for these trans movements Replication Server uses lot of threads(DSI,RSI,SQT,SQM etc).

If any one of thread stops , replication ceases , even it can hamper PDB performance.

Thats why it is little bit difficult to manage, not difficult, we can say, its need better monitoring.

If I am missing any thing , please add in comments.

Same Thread at :