There is no hard and fast answer to whether it is problemattic or not. It really depends a lot on what the impact of the page splitting is. If it creates waits or blocking/locking delays in your database then it may be problemattic. Unfortunately, finding out which specific object/index is getting the page split is not so intuitive. You can find the count of splits by object for the active portion of the transaction log with fn_dblog()

SQL 2005

select parsename([AllocUnitName], 3) [Schema],

parsename([AllocUnitName], 2) [TableName],

parsename([AllocUnitName], 1) [Index],

count([Current LSN])

from ::fn_dblog(null, null)

where Operation = N'LOP_DELETE_SPLIT'

group by parsename([AllocUnitName], 3), parsename([AllocUnitName], 2), parsename([AllocUnitName], 1)

SQL 2000

-- http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2004/11/27/37.aspx

select [Object Name], [Index Name], count([Current LSN])

from ::fn_dblog(null, null)

where Operation = N'LOP_DELETE_SPLIT'

group by [Object Name], [Index Name]

The examples above are based on Greg Linwoods blog post whose address is the comment on the SQL 2000 version. I just changed it to work for SQL 2005.

Somethings to consider when looking at page splits:

1. How many/how often are they occuring?

2. What is the actual impact to the system when they occur?

3. What is the residual impact to the system when they occur? (index fragmentation)

Once you consider the above, the way you go about fixing it is to change the fillfactor on the index in question and leave more freespace at the leaf level by rebuilding the index with the new fillfactor.