Gek ,Thank you very much

I am in doubt because the installation guide ,for the system requirements for Linux  , it just mentions Red Hat 6.x .

So the question is , assuming that  ASE 16.x can be installed on RHEL 7 , there is no information regarding specific patches nor  kernel nor gliblc, etc version requirements for the OS, I can assume   that if I stick to the PAM certification, there are no special installation requirements for

RH EL 7?

Regards

Jose

Hello Jose

the installation guide probably written before the certification on RHEL7.X is done.Hence it takes the OS version which ASE GA version build is on.

if there is no special requirement information on PAM,

we can take it as it is from the installation guide.Unless you know from REDHAT vendor on the certain critical patches.

cheers,

Gek

Gek

Thank you

Regrads

Jose

Hello,

Our application is getting a lot of the following errors :

Caused by:
com.sybase.jdbc4.jdbc.SybBatchUpdateException: JZ0BE: BatchUpdateException:
Error occurred while executing batch statement: The dynamic statement
'*sh1731692265_0874276115ss*' could not be found. This may be due to
insufficient metadata descriptors. Increase the serverwide 'number of open
objects' parameter or the 'procedure cache size' parameter.

sp_monitorconfig 'all' shows that number of open objects is used less then 60%.

I've increased the procedure cache size, but the problem persists.

It is always the same query, and the problem can be reproduced.

I have executed :

dbcc procbuf

and found the name mentioned in the error :

PROCBUF:

address=0xfffffd6db143acd8   id=1731692265   pbdbid=2 

pbplannum=95848061

pbuid=1   pbihash=0x0   pbnhash=0x0   pbprev=0xfffffd6db1cf8eb0

pbtimestamp: Jul 14 2015  3:43PM

pbnext=0xfffffd6dad0ee6e8   pbprochdr=0xfffffd6e9bd16000   pbparam=0x0   pbtype=4

pbstate=1   pbstat=0x0   pbusecnt=0   pbspid=0   pbdes=0xfffffd6dac1e2bb8   pbxdes=0x0

pbsqt_desc=0x0

pbname='*sh1731692265_0874276115ss*'   pbprocnum=1  pbsharecnt=0  pboldplan=0

pbhold=0  prbuf_link->next =fffffd6dac1e2d90  prbuf_link->prev=fffffd6dac1e2d90

PROC_HDRs:

Memory usage for all PROC_HDRs starting at 0xfffffd6e9bd16000

--------------------------------------------------------

PROC_HDR at 0xfffffd6e9bd16000

p_hdrstep=0x0   p_hdrseq=0xfffffd6eb4d8f1d8   p_hdrcrt=0x0

p_hdrpbuf=0xfffffd6db143acd8   p_hdrtmps=0x0   p_hdrcaller=0x0

p_hdrelease=0   p_hdrtabid=1731692265   p_hdrsub=0x0

p_hdrsubcnt=0   p_css=0x0   p_csscnt=0   

p_hdrstatus=1 ((0x00000001 (CACHED)))

p_hdrstat2=0 ((0x00000000))

p_lastpg=0  p_lastoff=3  p_procnum=0  p_hdrdbid=59 p_tmpdbid=0

p_lostcnt=14   p_hdrtype=1 p_pmctrlp=0xfffffd6e60bcbbe8

Memory Allocation Map:

0 mempgptr=0xfffffd6e9bd16000   pma_chunksize=2048   byte_count=2008   byte_save=2008

1 mempgptr=0xfffffd6ea97c2000   pma_chunksize=4096   byte_count=3168   byte_save=3168

2 mempgptr=0xfffffd6e8576d000   pma_chunksize=4096   byte_count=3824   byte_save=3824

3 mempgptr=0xfffffd6eb4d8e800   pma_chunksize=8192   byte_count=2992   byte_save=2992

Summary of memory usage:

    Total # of PROCHDRs used            : 1

    Total # of pages used               : 9

    Total # of bytes used               : 11992

    Total # of lost bytes for alignment : 14

    Total # of pages lost for alignment : 0

    Total percentage of memory lost     : 0

I want to remove this procedure from the cache.

The only command I know that accepts an id is purgesqlcache, but I assume that this removes an entrie from the statement cache.

Anyway, I gave it a try.

> dbcc purgesqlcache(1731692265);

DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
Statement (id=1731692265) not found in the cache.

Ok, as expected.

I ran dbcc proc_cache(free_unused) which removed the proc_buf above. (and a lot more :-) ).

I have to wait until tomorrow when our programmers are back at work to know if this solved the problem.

In the meanwhile I want to ask if there is something I'm missing, or if there are anything else I should try/execute when this problem persists/returns.

We're running ASE 15.7 SP134 on solaris intel.

Thanks,

Luc.

In addition, there are a lot of other items in proc cache - the formula Mike was using I suspect only dealt with proc plan sizes.   However the work plans, final execution plans for adhoc queries are also in proc cache, along with index stats during optimization, etc.

However, I suspect there is a different underlying cause.    One possibility is someone was silly enough to set 'number of sort buffers' to some value >2500.    If so, than any create index or update stats could cause proc cache to blow out (remember, the victim might not be the sort/stats - it could be a new prepared statement).     There are other cases where views get some weird issues and they have plan on disk that causes proc cache to be exceeded - you drop/recreate the view to clear the problem.

I would be taking a closer look at when the problem happens and what is running at the time - or looking in monProcedureCacheMemoryUsage as well as monCachedProcedures/monCachedStatements to get an idea of where proc cache consumption is at.   9G of proc cache is a lot for 120 users....extending to 14G doesn't make sense.....it is possible - e.g. extremely large subquery caching (which is also in proc cache), but......my gut says it is something else.

Hi Dawn,

Thanks a lot for your help! Unfortunately us traditional SAP'ers dont get to ISUG

So I finally got it working.  There is a package called "php5-sybase" (duh) that you can install with a simple:

'sudo apt-get install php5-sybase'

After that, you can use the standard PDO class for connecting!!!

Below is sample code to get anyone started:

<!doctype html>

  <body>

    <?php

      try {

        $hostname = "Ubuntu1";

        $port = 5000;

        $dbname = "tempdb";

        $username = "sa";

        $pw = "password";

        $dbh = new PDO ("dblib:host=$hostname:$port;dbname=$dbname","$username","$pw");

      } catch (PDOException $e) {

        echo "Failed to get DB handle: " . $e->getMessage() . "\n";

        exit;

      }

      $stmt = $dbh->prepare("select name from master..sysdatabases");

      $stmt->execute();

      $databases = $stmt->fetchAll();

    ?>

    <table>

      <thead>

        <tr>

          <th>Database</th>

        </tr>

      </thead>

      <tbody>

        <?php

        foreach ( $databases as $database ) {

          echo "<tr>";

          echo "<td>" . $database[0] . "</td>";

          echo "<tr>";

        }

        ?>

      </tbody>

    </table>

  </body>

</html>

This will output the following to your web browser:

Hi Kyle,

Thanks for the update.

Dawn

Rhishikesh,

Thanks - we do have some dynamic SQL - rather too much of it - but I wouldn't expect it to be as large as the number of procs we have.

However, we do have web processes which create a batch with a 100 lines of "insert into #tables values ()"

Would this cause a lot of procedure cache ie 2Gb or 3Gb for 120 users ?

I'd rather not disable statement cache but we could try it just to see how much is used.

Jeff,

> silly enough to set 'number of sort buffers' to some value >2500

Our sort buffers are set at 1000.

Assuming the amount of procedure cache required (in bytes): (Number of sort buffers) X (rows per page) X 100 and we're using 16k pages so will have a high number of rows per page (say 200)

then 1000 * 200 *100 is still only 20Mb.

(BTW would be good to extend the manual to say this - I only found it out by accident when performance degraded)

> There are other cases where views get some weird issues and they have plan on disk that cause

> proc cache to be exceeded - you drop/recreate the view to clear the problem.

We have some complex views so this could be affecting us. Is there a case for this ?

> you drop/recreate the view to clear the problem.

Wouldn't the problem just keep coming back - don't really want to do this regularly.

master..monCachedProcedures is really good but only shows 2Gb of plan usage at the moment

But I'll monitor this and see whats causing it.

Could it be that the procedure cache isn't being aged out

Thanks

Just to add the 2Gb of procedure cache (according to monCachedProcedures ) was for every proc and every dynamic SQ.

For us to use 9Gb of procedures cache at one time seems very unlikely.

I can see in sysmon that procedures are being removed from cache and written to disk.

Hi Community,

What I was wondering is whether there was something wrong with the current version but yesterday we installed the last release EBF 24487 and the issue was the same:

Adaptive Server Enterprise/16.0 SP01 PL02/EBF 24487 SMP/P/RS6000/AIX 6.1/ase160bw/3722/64-bit/FBO/Fri Jun  5 08:02:38 2015

After execute the command:

1> dump tran base with truncate_only

2> go

The log is empty.

Does Anyone know if there is any report with the same behavior working with ASE 16?

This is the ouptut sp_monitorconfig "all" after the issue:

Name                      Num_free    Num_active  Pct_act Max_Used    Reuse_cnt   Instance_Name

------------------------- ----------- ----------- ------- ----------- ----------- ------------------------------

additional network memory    42841156           0   0.00            0           0 NULL

audit queue size                  100           0   0.00            0           0 NULL

compression info pool siz        4090           6   0.15            7           0 NULL

disk i/o structures               256           0   0.00            0           0 NULL

heap memory per user             7913         295   3.59          307           0 NULL

kernel resource memory          14075       11615  45.21        11615           0 NULL

max cis remote connection         500           0   0.00            0           0 NULL

max memory                          0    50790400 100.00     50790400           0 NULL

max number network listen          14           1   6.67            1           0 NULL

max online engines                 15           1   6.25            1           0 NULL

memory per worker process        1024           0   0.00            0           0 NULL

number of alarms                   38          42  52.50           44           0 NULL

number of aux scan descri         256           0   0.00           15           0 NULL

number of devices                   2          28  93.33           28           0 NULL

number of dtx participant         500           0   0.00            0           0 NULL

number of java sockets            999          28   2.73           28           0 NULL

number of large i/o buffe           6           0   0.00            1           0 NULL

number of locks               2298573        1427   0.06        67945           0 NULL

number of mailboxes                30           0   0.00            0           0 NULL

number of messages                 64           0   0.00            0           0 NULL

number of open databases            2          12  85.71           12           0 NULL

number of open indexes          11062         938   7.82          938           0 NULL

number of open objects          89842       10158  10.16        10158           0 NULL

number of open partitions        8719        1281  12.81         1281           0 NULL

number of remote connecti          80           0   0.00            0           0 NULL

number of remote logins            20           0   0.00            0           0 NULL

number of remote sites             10           0   0.00            0           0 NULL

number of sort buffers              0        1632 100.00         1632           0 NULL

number of user connection         973          27   2.70           27           0 NULL

number of worker processe           0           0   0.00            0           0 NULL

partition groups                 1024           0   0.00            0           0 NULL

permission cache entries          299           1   0.33            1           0 NULL

procedure cache size          3343427      261053   7.24       262790           0 NULL

size of global fixed heap         300           0   0.00            0           0 NULL

size of process object he        3000           0   0.00            0           0 NULL

size of shared class heap        3072           0   0.00            0           0 NULL

size of unilib cache           409534         848   0.21          848           0 NULL

txn to pss ratio                16000           0   0.00            0           0 NULL

Thanks,

Anything reported in the ASE logfile?

You can enable logging for error 701: running out of procedure cache

This error is normally not reported in the ASE logfile, but would be useful to have logged

exec sp_altermessage 701, 'with_log', true

Dumb question, but did you apply the 'installmaster' script when up upgraded your ASE?

Chris

Hi Chris,

Yes, this is the sp_version output:

Script            Version Status  

----------------- ----------------------------------------------------------------------------------------------- --------

installcommit     16.0 SP01 PL02/EBF 24487 SMP/P/RS6000/AIX 6.1/ase160bw/3722/64-bit/OPT/Fri Jun  5 07:25:06 2015 Complete

installjdbc       jConnect (TM) for JDBC(TM)/1001/Thu May 28 00:00:00 2015 PDT                                    Complete

installmaster     16.0 SP01 PL02/EBF 24487 SMP/P/RS6000/AIX 6.1/ase160bw/3722/64-bit/OPT/Fri Jun  5 07:25:06 2015 Complete

installmodel      16.0 SP01 PL02/EBF 24487 SMP/P/RS6000/AIX 6.1/ase160bw/3722/64-bit/OPT/Fri Jun  5 07:25:06 2015 Complete

montables         16.0/24487/P/RS6000/AIX 6.1/ase160bw/3722/64-bit/OPT/Fri Jun 05 04:56:53 2015                   Complete

ODBC MDA Scripts 16.0.01.01.1014/Wed Mar 25 UTC 21:44:06 2015 Complete

OLEDB MDA Scripts 16.0.01.01.1014/Wed Mar 25 UTC 22:05:24 2015 Complete

Execution time: 0.043 seconds

Thanks,

Juan Carlos.

Hello Juan Carlos,
I would guess that you are not using ASE for SAP applications, as on that environment we *should* have the "trunc log on chkpt" disabled, and a dump with truncate_only *is not* recommended as it break the recoverability of the environment.
So I'll move the discussion to the SAP ASE for custom applications

Regarding the question: is the batch just doing updates of some bulk inserts?
Can we check the sp_dboptions of the concerned database ?

Just to keep in mind that the "trunc og on chkpt" will remote *committed transactions* from the transaction log.

Best regards,
Victoria.

Am working on Sybase ASE 15.5.

I have 2 databases created in the same server, "DatabaseA" and "DatabaseB". The database owner is "User".

Logging in as "User" I created a table in "DatabaseB", called "TableA".

Now, my user has access to both database, but the default database is "DatabaseA".

This is sucessful when i login to DatabaseA:

USE DatabaseB GO SELECT * from DatabaseB.User.TableA 
GO 

But this is not:

USE DatabaseA GO SELECT * from DatabaseB.User.TableA 
GO 

It tells me that there is "No such object or user exists in the database".

I have Googled and most sites say that if the user has rights, then you only need to append the database and owner name to the table to access it. But it does not seems to work for my case.

I have tried creating a non DBO user "User2", and assigning it select rights using

GRANT SELECT ON DatabaseB.User.TableA to User2 

and sp_helprotect shows that the rights is there for this user. But the results are exactly the same as when i query it with User.

Below is the result from sp_helprotect

grantor | grantee | type | action | object | column | grantable
'User' | 'User2' | 'Grant' | 'Select' | 'TableA' | 'All' | 'FALSE' 

Is there anything configuration or setting that needs to be checked to enable this?

Can you please check with creating a user named "guest" in the DatabaseB. This will enables any user with an Adaptive Server account to access the database as a guest user. If a user who has not been added to the database as a user or an aliased user issues the use database_name command, Adaptive Server looks for a guest user. If there is one, the user is allowed to access the database, with the permissions of the guest user.

The database owner can use sp_adduser to add a guest entry to the sysusers table of the database:
sp_adduser guest

Please also verify that the suid is -1 for guest user as below :

select suid, name from sysusers

~Regards Gaurav

Thanks

I tried

     reorg compact ETP partition p2021

and it didnt do anything. No improvement ?

It then did a reorg frowarded rows just in case but it made no difference.

The partition reports just 481,088 rows in it.

and systabstats reports 111,260 forwarded rows

Should "reorg forwarded_rows" work on all types of partitions ?

We partitioned the table so we could do maintenance per partition.

Don't even know if there's enough space to rebuild ? I'll have to kick it off at the weekend.

Why is there no rebuild possible on the partition ?

Hi Mike,

I assume this is a SAP ASE 16 Server then you maybe hit correction 768535 this was fixed in SAP ASE 16 SP01.

What the correction does fixes is that this should not happen again it will not fix the value if it is wrong before you upgrade to ASE 16 SP01, I only manage to correct the value with reorg rebuild. 

Thanks,

Niclas

No - we're on 15.7 SP134.

We were on 15.5 until Jan 2015 - when we moved to15.7 SP122.

Do you have a link to 768535 ?

I'm not clear about why a reorg forwarded_rows doesn't work. Whats happening that stops the

reorg working ?

Will this also mean that a reorg rebuild won't work either.

I'll kick one off on a test server to see.

Thanks

Mike