ASE

Sybase Adaptive Server Enterprise

Implementation of Function String in Sybase Replication Server(SRS)

0

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 : Linkedin.com

http://www.linkedin.com/groups/What-are-possible-usage-Function-3955841.S.65585220?qid=4eb177c2-d7e3-4572-9be4-92d640046c6c&trk=group_most_recent_rich-0-b-ttl&goback=%2Egmr_3955841

 

 

Inserting data into a data-only-locked heap table

0

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

0

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

0

Same has been updated in @http://sybaseblog.com/interviewquestions/
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

0

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.

Sybase Improves Performance with SAP Business Suite on ASE

0

Source : Sybase Ince on youtube

Benefits of Normalization

0

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
shorter.
• 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
data.

Happy,Healthy & Successful New Year 2012

0

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

 

 

 

 

 

 

 

ASE database for SAP ERP

0

Hello all,

These are copilataion for Sybase ASE on SAP from the Rob’s Blog :

Read Full Story : http://blogs.sybase.com/database/2011/12/so-what-does-an-ase-database-look-like-in-sap-erp/

  • SAP has released Business Suite on ASE version 15.7.
  • All SAP application data resides in a single ASE database. There is another small database for use by SAP tools.
  • The ASE database uses a 16KB page size.
  • For ERP only (i.e. not counting CRM and the other Business Suite modules), the database contains about 80,000 tables and 170,000 indexes. This is because SAP ERP has many features and functions, all with their own set of tables. SAP customers typically run only a subset of all those functions so in practice a large part of those 80,000 tables will always remain empty.
  • All SAP tables use datarowslocking (there is an interesting historical dimension.
  • All tables names are in uppercase; some table names contain special characters, like the slash character in “/BCV/C_QATTR” (I don’t have a clue what that name means, BTW)
  • Apart from the tables, there are also about 10,000 views. No stored procedures or triggers are used.
  • SAP makes heavy use of dynamic SQL (also known as “prepared statements”).
  • Many tables have a text or image column.
  • All tables are owned by one database user (and that’s not the dbouser).
  • The ASE database is accessed through ODBC.
  • SAP makes frequent use of the built-in ASE Job Scheduler (originally added in ASE 12.5.1).
  • The ASE server uses Unicode with the utf8 character set.

Guidelines for improving I/O performance

0

The major guidelines for improving I/O performance in Adaptive Server are as follows:

• Spreading data across disks to avoid I/O contention.

• Isolating server-wide I/O from database I/O.

• Separating data storage and log storage for frequently updated databases.

• Keeping random disk I/O away from sequential disk I/O.

• Mirroring devices on separate physical disks.

• Partitioning tables to match the number of physical devices in a segment.

Go to Top