Archive for January, 2012

Implementation of Function String in Sybase Replication Server(SRS)

January 30th, 2012 No comments

These experience shared by  Senior DBAs as name mentioned, Hope this  will help you to understand more about function string from implementation point of view in a Replication environment: 
Craig Oakley , Senior DBA.

We used function strings when we wanted to replicate all columns to some servers, and only selected columns to other (web-facing) servers. This was particularly useful before Rep Server allowed multiple RepDefs on the same table. One concern was text columns which were not being replicated to the web-facing server: we had to create a function string to get a text pointer (we used a one-row table and just update all the text columns on top of each other, as the value was not needed on that server): failure to get a text pointer cause the DSI to go down, and we could not specify that as a condition to ignore.

Beyond this, I would imagine function strings could help specify how you want the update to be done, which could be a performance improvement. It would also allow for a different implementation at the replicate than there is at the primary (such as a table at the primary being two joined tables at the replicate).


Sukhesh Nair, Senior Sybase DBA

We used to have a setup where data was replicated from sybase to oracle as also to a warm standby sybase server. Rep Server function strings helped in filtering data that would need to be passed to Oracle. It helped immensely in streamlining the data flow to targets by manipulating the incoming data through function string. I feel it is one of the most advanced and useful yet very less used capabilities of Sybase Rep Server.
The deterrent could be because of the complexity it would introduce to the replication system. The setup we had worked wonderfully and never gave us any major problems. Without proper monitoring (which needs to be scripted by DBAs) it used to be hard to maintain. Many of the current Rep Server administrators I see do not have adequate knowledge or experience of handling function strings.

Rey Wang , Senior Sybase DBA

You can map the delete to no op with functional string.

Partha Gogoi Senior DBA

We use function strings to transform data at the replicate..We have databases being replicated from Toronto and New York to London, Sydney and Singapore and the client ids are transformed at the replicate because, as per business requirements, the client ids are different at each site.. Of course , having a Universal client id would simplify things , but the systems and databases at each site grew independently until replication was set up and it would be a lot of rework to change all the client ids at the replicate sites

Øystein Grinaker Senior DBA

A Function String could be used to change default behaviour.
Say you delete a row in a table on PDB, but you do not want to delete the row on the RDB. Then make a change in rs_delete. You may make the rs delete just to make a logical delete by updateing a deletemarker for that spesific row.


Source :



Multi-Path Replication (MPR) technology : Replication Server 15.7

January 7th, 2012 No comments

 The imminent release of Replication Server 15.7 continues pushing envelop and maintaining its leading edge by introducing new Multi-Path Replication (MPR) technology.

So, what is MPR? MPR improves replication performance and reduces latency by enabling parallel paths of data from the source database to the target database. These parallel paths will process data independently of each other to improve overall efficiency, performance and load balancing.

Full Source @

Note :

 What about the order of transacation , that need to maintain at target side?
Even transaction can come rapidally at target , but it must be applying in a order.

Commit order is maintained within single path. To increase performance on a single path, one can employ parallel DSI, Bulk copy and HVAR features RS has introduced in earlier releases. To take advantage of MPR, users need to fully understand application schema to divide them as commit order is not guaranteed among paths.


Categories: News, Replication Server Tags:

Inserting data into a data-only-locked heap table

January 5th, 2012 No comments

When users insert data into a data-only-locked heap table, Adaptive Server tracks page numbers where the inserts have recently occurred, and keeps the page number as a hint for future tasks that need space. Subsequent inserts to the table are directed to one of these pages. If the page is full, Adaptive Server allocates a new page and replaces the old hint with the new page number.

Blocking while many users are simultaneously inserting data is much less likely to occur during inserts to data-only-locked heap tables. When blocking occurs, Adaptive Server allocates a small number of empty pages
and directs new inserts to those pages using these newly allocated pages as hints.

For datarows-locked tables, blocking occurs only while the actual changes to the data page are being written; although row locks are held for the duration of the transaction, other rows can be inserted on the page. The row-level locks allow multiple transaction to hold locks on the page.

If conflicts occur during heap inserts
Conflicts during inserts to heap tables are greatly reduced for data-onlylocked tables, but can still take place. If these conflicts slow inserts, some workarounds can be used, including:

• Switching to datarows locking, if the table uses datapages locking
• Using a clustered index to spread data inserts
• Partitioning the table, which provides additional hints and allows new pages to be allocated on each partition when blocking takes place

Inserting data into an allpages-locked heap table

January 5th, 2012 No comments

When you insert data into an allpages-locked heap table, the data row is always added to the last page of the table. If there is no clustered index on a table, and the table is not partitioned, the sysindexes.root entry for the heap table stores a pointer to the last page of the heap to locate the page
where the data needs to be inserted.

If the last page is full, a new page is allocated in the current extent and linked onto the chain. If the extent is full, Adaptive Server looks for empty pages on other extents being used by the table. If no pages are available, a new extent is allocated to the table.

Conflicts during heap inserts
If many users are trying to insert into an allpages-locked heap table at the same time, each insert must
wait for the preceding transaction to complete.

This problem of last-page conflicts on heaps is true for:
• Single row inserts using insert
• Multiple row inserts using select into or insert…select, or several insert statements in a batch
• Bulk copy into the table

Some workarounds for last-page conflicts on heaps include:
• Switching to datapages or datarows locking
• Creating a clustered index that directs the inserts to different pages
• Partitioning the table, which creates multiple insert points for the table, giving you multiple “last pages” in an allpages-locked table

Sybase Interview Questions

January 4th, 2012 No comments

Same has been updated in @
How can we configure the dbcc database?

How can you configure sybsecurity?

Have you ever worked on terabyte size of  database? How are you taking backup for the same?

Whats the diff between MSA and WS?  Can we consider MSA as a Ws?

You are not able to execute any command in ASE as tempdb is full and you cant create user defined tempdb on the fly , how will you investigate ?

What are the new features fo Sybase ASE 15?

What are the different options avilable with reorg ?

Why we require reorg ?

Suppose if every thing is fine in REplication enviorment  and data is not replicating , how will you troubleshoot the same?

What is gen id in rep server?

How can you check the latency in the replication enviorment?

Whats is HA in Sybase? How can we monitor the HA status?


Adaptive Server pages

January 3rd, 2012 No comments

The size of Adaptive Server‘s logical pages (2K, 4K, 8K, or 16K) determines the server’s space allocation. Each allocation page, object allocation map (OAM) page, data page, index page, text page, and so on
are built on a logical page. For example, if the logical page size of Adaptive Server is 8K, each of these page types are 8K in size. All of these pages consume the entire size specified by the size of the logical page. OAM pages have a greater number of OAM entries for larger logical pages (for example, 8K) than for smaller pages (2K).

The logical page size is a server-wide setting; you cannot have databases with varying size logical pages within the same server. All tables are appropriately sized so that the row size is no greater than the current page size of the server. That is, rows cannot span multiple pages.

Categories: ASE Tags:

Sybase Improves Performance with SAP Business Suite on ASE

January 3rd, 2012 No comments

Source : Sybase Ince on youtube


Categories: ASE Tags:

Sybase IQ : Architecture & Benefits

January 3rd, 2012 No comments

Sybase IQ ??

Sybase® IQ is a high-performance decision-support server designed specifically for data warehousing.

Sybase IQ is part of the Sybase product family that includes Adaptive Server Enterprise and SQL Anywhere. Component Integration Services within Sybase IQ provide direct access to relational and nonrelational databases on mainframe, UNIX, or Windows servers.


Architecture ??

Sybase IQ architecture differs from most relational databases. Sybase IQ focuses on readers, not writers, which provides a fast query response for many users.

Data is stored in columns, not rows

Placing indexes on all columns provides a performance advantage

A large page size provides a performance advantage

A large temporary cache provides a performance advantage for most operations

Access to data occurs at the table level

Most query results focus on data at the table level

Most insertions and deletions write data for an entire table, not for a single row.


Benefits ??
Sybase IQ is a decision support system optimized to deliver superior performance for mission-critical business solutions.

Intelligent query processing that use index-only access plans to process any type of query.

Ad hoc query performance on uniprocessor and parallel systems.

Multiplex capability for managing large query loads in a multi-server configuration.

Fully-flexible schema support.

Efficient query execution without query-specific tuning under most circumstances.

Fast initial and incremental loading.

Fast aggregations, counts, comparisons of data.

Parallel processing optimized for multi-user environments.

Stored procedures.

Increased productivity due to reduced query time.

Entire database and indexing stored in less space than raw data.

Reduced input/output (I/O).

Benefits of Normalization

January 2nd, 2012 No comments

Normalization produces smaller tables with smaller rows:
• More rows per page (less logical I/O)
• More rows per I/O (more efficient)
• More rows fit in cache (less physical I/O)
• Searching, sorting, and creating indexes is faster, since tables are
narrower, and more rows fit on a data page.
• Index searching is often faster, since indexes tend to be narrower and
• More tables allow better use of segments to control physical
placement of data.
• You usually have fewer indexes per table, so data modification
commands are faster.
• You usually have more tables. You can have more clustered indexes (one per table), so you get more
flexibility in tuning queries.
• Fewer null values and less redundant data, making your database
more compact.
• Triggers execute more quickly if you are not maintaining redundant

Categories: ASE Tags:

Happy,Healthy & Successful New Year 2012

January 1st, 2012 No comments

Wishing You Happy , Healthy & Successful New Year 2012!   Happy Learning Sybase!








Categories: ASE Tags: