GET PERAS

Hii All
Can i use RP_PROVIDE_FROM_LAST after GET PERAS??
I want to fetch from infotype 0760. How can i fetch data from infotype 0760??
It is throwing error if i use macros.
Tx

Hi,
Get peras is used for logical data base PNPCE.
Get pernr is used for logical data base PNP.
Example 1: For PNP
TABLES: pernr.
INFOTYPES: 0000, 0001, 0007.
start-of-selection.
Get Event starts
GET pernr.
Here you can refer pernr-pernr.
Example 2: For PNPCE
NODES: peras.
TABLES: pernr.
INFOTYPES: 0000, 0001, 0007.
start-of-selection.
Get Event starts
GET peras.
Here you can refer peras-pernr.
Edited by: Velangini Showry Maria Kumar Bandanadham on May 7, 2008 4:00 PM

Similar Messages

Sudden increase in buffer gets per executions in update statement

Hi,
Recently we have encountered one performance issue, which is most likely caused by a sudden increase in the buffer gets per execution.
The SQL is an update statement, updating a table using a primary key (we have checked to confirm the running execution plan is using the primary key), and one field being updated is a BLOB column.
As shown in the below statistics, there is no major change in the number of executions during the every 20 minutes monitoring interval. However, the buffer gets per executions has been more than double, and the CPU time is almost doubled, hence the exec_time (elapsed time) has been doubled.
The same SQL has been running for the past four years in multiple similar databases. The database is Oracle 9.2.0.4 running on Solaris 9. For the past 300 days, the average elapsed time per execution is about 0.0093s, while the average buffer gets per execution is about 670. The update statement has been executed about 9 times per second.
The question is why there is a sudden increase in the buffer gets? The sudden increase happened twice for the past two days.
<pre>
B_TIME E_TIME EXECUTIONS_DIFF EXEC_TIME CPU_TIME BUFFER_GETS EXEC_PER_DAY
2009-11-25-14:04 2009-11-25-14:23 8513 .0069 .0068 315.56 646329
2009-11-25-14:23 2009-11-25-14:43 10170 .007 .0068 312.28 726188
2009-11-25-14:43 2009-11-25-15:05 11873 .0072 .0069 320.17 787885
2009-11-25-15:05 2009-11-25-15:23 8633 .011 .0101 844.83 675014
2009-11-25-15:23 2009-11-25-15:44 9668 .0144 .0137 1448.51 680778
2009-11-25-15:44 2009-11-25-16:04 9671 .0163 .0156 1809.04 702163
2009-11-25-16:04 2009-11-25-16:25 10260 .0188 .0177 2107.67 711447
2009-11-25-16:25 2009-11-25-16:44 9827 .0157 .0151 1834.3 739593
2009-11-25-16:44 2009-11-25-17:05 10586 .0171 .0164 2008.25 714555
2009-11-26-08:04 2009-11-26-08:24 11028 .0182 .0172 1979.61 800688
2009-11-26-08:24 2009-11-26-08:44 10533 .0154 .0149 1734.62 750248
2009-11-26-08:44 2009-11-26-09:04 9367 .018 .0168 2043.95 685274
2009-11-26-09:04 2009-11-26-09:24 10307 .0214 .0201 2552.43 729938
2009-11-26-09:24 2009-11-26-09:45 10932 .0251 .0234 3111.48 762328
2009-11-26-09:45 2009-11-26-10:05 10992 .0278 .0254 3386.41 797404
2009-11-26-15:03 2009-11-26-15:16 7183 .0425 .0348 4615.42 746824
2009-11-26-15:16 2009-11-26-15:23 2921 .0417 .0373 4887.75 682092
2009-11-26-15:23 2009-11-26-15:43 9597 .0393 .0352 4603.62 679656
2009-11-26-15:43 2009-11-26-16:03 8797 .0411 .0362 4783.66 630755
2009-11-26-16:03 2009-11-26-16:23 9957 .0453 .0391 5168.28 718100
2009-11-26-16:23 2009-11-26-16:43 11209 .0436 .0369 4870.77 808395
2009-11-26-16:43 2009-11-26-17:03 10729 .0428 .0375 5119.56 766103
2009-11-26-17:03 2009-11-26-17:23 9116 .0409 .0363 4912.58 659098
</pre>
Yesterday I did a trace on one of the sessions running the update statement, and below is the tkprof output:
<pre>
call count cpu elapsed disk query current rows
Parse 76 0.03 0.00 0 0 0 0
Execute 76 4.58 5.14 0 567843 19034 76
Fetch 0 0.00 0.00 0 0 0 0
total 152 4.61 5.14 0 567843 19034 76
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 88
Rows Row Source Operation
1 UPDATE (cr=30 r=0 w=0 time=6232 us)
1 INDEX UNIQUE SCAN <PK Index Name> (cr=3 r=0 w=0 time=58 us)(object id 81122)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
Waited--------------------------------------------------------------------------------
SQL*Net message to client 152 0.00 0.00
SQL*Net message from client 152 0.00 0.22
SQL*Net more data from client 1894 0.00 0.03
SQL*Net break/reset to client 152 0.00 0.00
buffer busy waits 14 0.00 0.00
enqueue 1 0.61 0.61
</pre>
GaoYuan

Hi,
I've reformatted your output for better understanding (with {noformat}...{noformat}):
B_TIME           E_TIME           EXECUTIONS_DIFF EXEC_TIME   CPU_TIME BUFFER_GETS EXEC_PER_DAY
2009-11-25-14:04 2009-11-25-14:23            8513      .0069      .0068      315.56       646329
2009-11-25-14:23 2009-11-25-14:43           10170       .007      .0068      312.28       726188
2009-11-25-14:43 2009-11-25-15:05           11873      .0072      .0069      320.17       787885
2009-11-25-15:05 2009-11-25-15:23            8633       .011      .0101      844.83       675014
2009-11-25-15:23 2009-11-25-15:44            9668      .0144      .0137     1448.51       680778
2009-11-25-15:44 2009-11-25-16:04            9671      .0163      .0156     1809.04       702163
2009-11-25-16:04 2009-11-25-16:25           10260      .0188      .0177     2107.67       711447
2009-11-25-16:25 2009-11-25-16:44            9827      .0157      .0151      1834.3       739593
2009-11-25-16:44 2009-11-25-17:05           10586      .0171      .0164     2008.25       714555
2009-11-26-08:04 2009-11-26-08:24           11028      .0182      .0172     1979.61       800688
2009-11-26-08:24 2009-11-26-08:44           10533      .0154      .0149     1734.62       750248
2009-11-26-08:44 2009-11-26-09:04            9367       .018      .0168     2043.95       685274
2009-11-26-09:04 2009-11-26-09:24           10307      .0214      .0201     2552.43       729938
2009-11-26-09:24 2009-11-26-09:45           10932      .0251      .0234     3111.48       762328
2009-11-26-09:45 2009-11-26-10:05           10992      .0278      .0254     3386.41       797404
2009-11-26-15:03 2009-11-26-15:16            7183      .0425      .0348     4615.42       746824
2009-11-26-15:16 2009-11-26-15:23            2921      .0417      .0373     4887.75       682092
2009-11-26-15:23 2009-11-26-15:43            9597      .0393      .0352     4603.62       679656
2009-11-26-15:43 2009-11-26-16:03            8797      .0411      .0362     4783.66       630755
2009-11-26-16:03 2009-11-26-16:23            9957      .0453      .0391     5168.28       718100
2009-11-26-16:23 2009-11-26-16:43           11209      .0436      .0369     4870.77       808395
2009-11-26-16:43 2009-11-26-17:03           10729      .0428      .0375     5119.56       766103
2009-11-26-17:03 2009-11-26-17:23            9116      .0409      .0363     4912.58       659098
call     count       cpu    elapsed       disk      query    current        rows
Parse       76      0.03       0.00          0          0          0           0
Execute     76      4.58       5.14          0     567843      19034          76
Fetch        0      0.00       0.00          0          0          0           0
total      152      4.61       5.14          0     567843      19034          76
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 88
Rows     Row Source Operation
      1 UPDATE (cr=30 r=0 w=0 time=6232 us)
      1   INDEX UNIQUE SCAN <PK Index Name(cr=3 r=0 w=0 time=58 us)(object id 81122)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
SQL*Net message to client                     152        0.00          0.00
SQL*Net message from client                   152        0.00          0.22
SQL*Net more data from client                1894        0.00          0.03
SQL*Net break/reset to client                 152        0.00          0.00
buffer busy waits                              14        0.00          0.00
enqueue                                         1        0.61          0.61
********************************************************************************Can you please provide a DDL for the table, indexes, type of the tablespace(s) they reside in (ASSM/MSSM, extents sizes), the UPDATE statement, how many sessions on average/peaks are doing the same thing concurrently, how many sessions are working this table concurrently and how do they use it?

High Logical reads/gets per exec

Hi,
Oracle version - 11.2.0.2
I am facing high gets/exec for queries.The queries are fine tuned with proper index usage.I checked with SQL tuning set also which says 'no recommendation for this query'.
We have sufficient SGA and shared pool size.Gets/per exec are in 9000 range.
Also I am seeing latch:cache buffer chains in top events which is happening for a delete query.Will altering freelist for this table help?
Kindly assist me with this.
Thanks.

Hi,
A bit late but PFB the trace file contents.
TKPROF: Release 11.2.0.2.0 - Development on Thu Oct 24 21:39:25 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: PADB_ora_65339438_NISTRY1.trc
Sort options: default
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
The following statement encountered a error during parse:
BEGIN :B1 := 'DOP';SQL>; END;
WAIT #45735296
Error encountered: ORA-06550
SQL ID: bt3nb4jyxdhnk Plan Hash: 0
BEGIN dbms_monitor.session_trace_enable(waits=>true, binds=>true); END;
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        1      0.00       0.00          0          0          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       1        0.00          0.00
SQL*Net message from client                     1       13.03         13.03
SQL ID: bdbaumr2rur17 Plan Hash: 0
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          0          0           0
Misses in library cache during parse: 0
Parsing user id: 93
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       1        0.00          0.00
SQL*Net message from client                     1       30.60         30.60
SQL ID: 715kzr79k99cw Plan Hash: 0
BEGIN :B2:=400013; END;
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          0          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       2        0.00          0.00
SQL*Net message from client                     2       11.56         18.88
SQL*Net break/reset to client                   1        0.00          0.00
SQL ID: 7usux68w7hu01 Plan Hash: 0
BEGIN :B1 := 'DOP'; END;
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          0          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       1        0.00          0.00
SQL*Net message from client                     1       15.50         15.50
SQL ID: 3hvm4jjpfx0zb Plan Hash: 1496842891
SELECT ADD_LINE1, ADD_LINE2, ADD_LINE3, DOMICILE, CITY, ZIP, ORGKEY
FROM
ADD WHERE ADD.ACTID = :B2 AND ADD.ADDCATEGORY =
'Mail' AND ADD.START_DATE<SYSDATE AND ADD.END_DATE>SYSDATE AND
BANK_ID = :B1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          1          6          0           1
total        4      0.00       0.01          1          6          0           1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         1          1          1 TABLE ACCESS BY INDEX ROWID ADD (cr=6 pr=1 pw=0 time=4193 us cost=1 size=163 card=1)
         2          2          2   INDEX RANGE SCAN IX_ADD_ACCID_NEW (cr=4 pr=0 pw=0 time=28 us cost=1 size=0 card=2)(object id 79696)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       2        0.00          0.00
Disk file operations I/O                        1        0.00          0.00
db file sequential read                         1        0.00          0.00
SQL*Net message from client                     1        0.00          0.00
SQL ID: 96g93hntrzjtr Plan Hash: 841937906
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#,
sample_size, minimum, maximum, distcnt, lowval, hival, density, col#,
spare1, spare2, avgcln
from
hist_head$ where obj#=:1 and intcol#=:2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute     19      0.00       0.00          0          0          0           0
Fetch       19      0.00       0.01          2         76          0          19
total       39      0.00       0.01          2         76          0          19
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS   (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         1          1          1 TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=4 pr=0 pw=0 time=42 us)
         1          1          1   INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=3 pr=0 pw=0 time=32 us)(object id 427)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         2        0.00          0.01
SQL ID: db78fxqxwxt7r Plan Hash: 2324581405
select /*+ rule */ bucket, endpoint, col#, epvalue
from
histgrm$ where obj#=:1 and intcol#=:2 and row#=:3 order by bucket
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      5      0.00       0.00          0          0          0           0
Fetch        5      0.01       0.01          4         15          0          53
total       11      0.01       0.01          4         15          0          53
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS   (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         3          3          3 SORT ORDER BY (cr=3 pr=2 pw=0 time=8455 us cost=0 size=0 card=0)
         3          3          3   TABLE ACCESS CLUSTER HISTGRM$ (cr=3 pr=2 pw=0 time=8428 us)
         1          1          1    INDEX UNIQUE SCAN I_OBJ#_INTCOL# (cr=2 pr=1 pw=0 time=4210 us)(object id 422)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         4        0.00          0.01
Disk file operations I/O                        1        0.00          0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        4      0.00       0.00          0          0          0           0
Execute      5      0.00       0.00          0          0          0           3
Fetch        2      0.00       0.00          1          6          0           1
total       11      0.00       0.01          1          6          0           4
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       7        0.00          0.00
SQL*Net message from client                     6       30.60         78.03
SQL*Net break/reset to client                   1        0.00          0.00
db file sequential read                         1        0.00          0.00
Disk file operations I/O                        1        0.00          0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute     24      0.00       0.00          0          0          0           0
Fetch       24      0.01       0.02          6         91          0          72
total       50      0.01       0.03          6         91          0          72
Misses in library cache during parse: 2
Misses in library cache during execute: 2
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         6        0.00          0.02
Disk file operations I/O                        1        0.00          0.00
    5 user SQL statements in session.
    2 internal SQL statements in session.
    7 SQL statements in session.
Trace file: PADB_ora_65339438_NISTRY1.trc
Trace file compatibility: 11.1.0.7
Sort options: default
       1 session in tracefile.
       5 user SQL statements in trace file.
       2 internal SQL statements in trace file.
       7 SQL statements in trace file.
       7 unique SQL statements in trace file.
     495 lines in trace file.
      78 elapsed seconds in trace file.
Thanks,
Nisha

ABAP-HR GET-PERAS , SlOW PERFORMANCE

Hi All,
I am using PNPCE LDB and while fetching records it takes lot of time .As per ST05 , time is taken by standard select statements inside GET PERAS.
Can any one advice , what should we do so that performance increases .
Should I use normal select statement.Will that help

Hi Ravi,
There is no macro which can retrieve the record based on AEDTM. One more thing to say is statement provide ...endprovide statement can be used and there would be no performance issue if i am not wrong. Anyway try this code.
tables: pa0001, pernr.
infotypes : 0001.
data : begin of itab occurs 0,
       pernr like pa0001-pernr,
       aedtm like pa0001-aedtm,
       end of itab.
data : v_aedtm type pa0001-aedtm.
start-of-selection.
v_aedtm = sy-datum - 1.
get pernr.
provide * from p0001 between pn-begda and pn-endda.
if p0001-aedtm = v_aedtm.
move : p0001-pernr to itab-pernr,
       p0001-aedtm to itab-aedtm.
       append itab.
endif.
endprovide.
end-of-selection.
loop at itab.
write :/ itab-pernr, itab-aedtm.
endloop.
Regards,
Kranthi

Subtype authorisation of "GET PERAS"

Can "GET PERAS" authority check by subtype?
For example..
I create a authorisation about the use can read just "IT0006 subtype 1".
I can check "IT0006 subtype 1" in pa30.
But I can't check "IT0006 subtype 1" in report program which program use "GET PERAS."
I think that if I don't have all subtype authorisation I can't check the infotype record by "GET PEARS".
Is it a specification?
Message was edited by:
Makoto Nishiwaki

Hello Patricia
The problem here is that you are using your ZMMBUS2012 in your workflow. You should use the original business object BUS2012.
Have you remembered to delegate your new subtype to BUS2012 ? (you do this in trx SWO1 Settings -> Delegate).
When you have done this, your new attributes/methods will be "inherited" from your subtype ZMMBUS2012 to BUS2012, and they will be availabel on the original object - BUS2012 - in your workflow.
Regards
Morten Nielsen

Problem with Get PERAS

Hi,
I am using PNPCE LDB, and Get PERAS statement. I am fetching infotype 0001. When i see the content of P0001 after Get PERAS, I only see the latest record for the employee. His previous records are not getting populated.
If i use Get PERNR, P0001 contains both the latest record as well as history records.
Why am I not able to get history records using PERAS? any insights?
-Krishna

Hi Krishna
you are getting only one record in GET PERAS because in your selection screen,
REPORTING PERIOD = today
Please select
REPORTING PERIOD = other 01.01.1900 to 31.12.9999
you will get all records
will i be rewarded

Get PERAS Returning Mulitple Records For PERNR

I have a program that is preloading PNPPERNR with PERNRS from a database before the GET PERAS statement. We just did an upgrade of some of our HR SAP Components and now the GET PERAS statement is triggering every time if sees a given PERNR in the PNPPERNR whereas before it only did it once even though the number of PERNRS in the PNPPERNR table is exactly the same.
We upgraded all of our SAP-HR* components from Release 604 SP-Level 67 to SP-Level 75 and the EA-HR* from Release 605 SP-Level 0044 to SP-Level 0052. We've tested the program in a client that hasn't been updated and then ran in an updated one and that is how we found the problem. Obviously SAP has updated something. Has anybody experienced this problem?

Hello,
The max rows operation is applied independently from the firstResults opperation, and is applied first. So in setting max rows to 2, you are getting rows 1 and 2, and then by applying firstResults=2, you are skipping past the second row, hence getting 0 back. This is because Max rows is applied to the statement before execution, where as firstResult is applied to the returned resultset. You will need to use firstresults=2 and maxrows=4 to get rows 3+4.
Also, you can change the query parameters on a named query. It is not recommended though only because named queries are stored on the session, and so in a multi-threaded app can cause problems when two threads try to execute the same query with, for example, different max results set. In a multithreaded environment you might want to get the named query and clone it before changing first/max rows, but for single threaded app there shouldn't be any problems.
Best Regards,
Chris

How much usage are you getting per charge?

Hello all!
I have heard stories from others about crappy battery life, so I decided to keep track of the last 2 charging periods to see how much usage I was getting per charge.
So far, I have had over 9 hours usage and over 2 days standby time on each of the last 2 charges. Probably 25% talk and 75% internet, email, iPod.
How is your battery doing?

I had to reset my phone, because it shut off as I ran the ipod and left wifi on in my leather case and the unit decided to "chill" literally. Everything was back on 10 minutes later. That being said, with no meter to look at,
Today I made at least 20-25 phone calls, the longest about 15 minutes. I left my bluetooth on all day, with wifi on probably 5-6 hours. Throw in a good 2 hours of IPOD usage and about 20-30 minutes at diferrent times showing of the iphone to a couple vendors and a customer. My phone was in use for 12 hours(what I would consider pretty heavy usage) and I recharged this evening in about 3 hours.
I am pretty pleased with the battery time. Tonight a recharged the battery and had the little space left. After reading another post I unplugged the cord from the AC adapter and plugged into my macbook and synced it and I now have the green glow everyone is so eager to see.

PNPCE Questions Regarding GET PERSON and GET PERAS

Any information regarding the runtime performance of PNPCE? It seems it takes a lot more time than PNP? Any suggestions how to improve performance while using PNPCE?
Message was edited by:
Shuvo Datta

Shuvo,
I found this on SE36, documentation on PNPCE logical database:
"<u>Selection Fields of the 0000 and 0001 Infotypes</u>
<i>You can use all the standard fields of the 0000 and 0001 infotypes for selection. You can also use additional selection fields that are the concatenation of two or more of these infotype fields. If possible, do not use these concatenated fields because they do not play a significant role in the selection and can lead to long runtimes in certain circumstances. You can show and hide the required selection fields using the Selection Fields function in the application toolbar. The report
category defines a preselection of fields that should be available."</i>
Also, I suggest you read the full doco in SE36 to use this LDB in a more efficient way as far as the performance is concerned.
Hope this helps.
Reward points if useful.
Cheers,
Sougata.

FBL5N - printing per customer and per total one sheet

Hello @ all,
we tried to print open items report, but we get per sheet one customer and the total on an other sheet. The print out is like this too big. How can we change the settings for the printing?
We like to have the list subsequently.
Thanks in advance for your help

Hi,
Try to get to Subtotals (Ctrl+F1) and in the Sort fields delete the * in the last column (column GW).
Regards,
Adela

Performance / buffer gets

Hi all,
possible someone could help me on following issue:
I'm working for a software vendor and one of our customers is reporting that especially 2 of the sql statements of our application are " executed ineffective" on their database environment.
They are especially saying that "These statements are consuming a lot of CPU and doing a lot of buffer gets in relation to the number of executions."
They provided following extracts out of the statspack report.
SQL1:
SQL Statistics
~~~~~~~~~~~~~~
-> CPU and Elapsed Time are in seconds (s) for Statement Total and in
   milliseconds (ms) for Per Execute
                                                       % Snap
                     Statement Total      Per Execute   Total
        Buffer Gets:         322,101             16.6     .89
         Disk Reads:             631              0.0     .48
     Rows processed:          19,444              1.0
     CPU Time(s/ms):              19              1.0
Elapsed Time(s/ms):              26              1.3
              Sorts:               0               .0
        Parse Calls:              -2              -.0
      Invalidations:               0
      Version count:               1
    Sharable Mem(K):              43
         Executions:          19,444 SQL2:
SQL Statistics
~~~~~~~~~~~~~~
-> CPU and Elapsed Time are in seconds (s) for Statement Total and in
   milliseconds (ms) for Per Execute
                                                       % Snap
                     Statement Total      Per Execute   Total
        Buffer Gets:         628,517             22.9    3.26
         Disk Reads:             128              0.0     .18
     Rows processed:          27,492              1.0
     CPU Time(s/ms):              27              1.0
Elapsed Time(s/ms):              30              1.1
              Sorts:               0               .0
        Parse Calls:               0               .0
      Invalidations:               0
      Version count:               1
    Sharable Mem(K):              39
         Executions:          27,492 The SQL1 is an update and SQL2 an Insert on the same table.
The accessed table has 6 indexes and a primary key column. On SQL1, the update, the where condition is reffering to the primary key column.
Both statements are using bind variables.
From my point, I would say, that the customer should provide the execution plan of both statements to verify that SQL1 is using the primary key.
As far as I understand "buffer gets" this issn't an issue because it's only saying that the data coumes out of the cache (which would be good) instead of reading the data from disk.
But I don't really see there any bottleneck.
Could you please give me some suggestions?
Many Thanks
Joerg

Hi,
Recently we have encountered one performance issue, which is most likely caused by a sudden increase in the buffer gets per execution.
The SQL is an update statement, updating a table using a primary key (we have checked to confirm the running execution plan is using the primary key), and one field being updated is a BLOB column.
As shown in the below statistics, there is no major change in the number of executions during the every 20 minutes monitoring interval. However, the buffer gets per executions has been more than double, and the CPU time is almost doubled, hence the exec_time (elapsed time) has been doubled.
The same SQL has been running for the past four years in multiple similar databases. The database is Oracle 9.2.0.4 running on Solaris 9. For the past 300 days, the average elapsed time per execution is about 0.0093s, while the average buffer gets per execution is about 670. The update statement has been executed about 9 times per second.
The question is why there is a sudden increase in the buffer gets? The sudden increase happened twice for the past two days.
<pre>
B_TIME E_TIME EXECUTIONS_DIFF EXEC_TIME CPU_TIME BUFFER_GETS EXEC_PER_DAY
2009-11-25-12:23 2009-11-25-12:43 9363 .0081 .008 530.04 671338
2009-11-25-12:43 2009-11-25-13:03 11182 .0083 .008 538.59 799772
2009-11-25-13:03 2009-11-25-13:23 10433 .0078 .0077 474.61 761970
2009-11-25-13:23 2009-11-25-13:43 10043 .008 .0078 496.65 713581
2009-11-25-13:43 2009-11-25-14:04 8661 .0076 .0074 401.22 598169
2009-11-25-14:04 2009-11-25-14:23 8513 .0069 .0068 315.56 646329
2009-11-25-14:23 2009-11-25-14:43 10170 .007 .0068 312.28 726188
2009-11-25-14:43 2009-11-25-15:05 11873 .0072 .0069 320.17 787885
2009-11-25-15:05 2009-11-25-15:23 8633 .011 .0101 844.83 675014
2009-11-25-15:23 2009-11-25-15:44 9668 .0144 .0137 1448.51 680778
2009-11-25-15:44 2009-11-25-16:04 9671 .0163 .0156 1809.04 702163
2009-11-25-16:04 2009-11-25-16:25 10260 .0188 .0177 2107.67 711447
2009-11-25-16:25 2009-11-25-16:44 9827 .0157 .0151 1834.3 739593
2009-11-25-16:44 2009-11-25-17:05 10586 .0171 .0164 2008.25 714555
2009-11-25-17:05 2009-11-25-17:24 9625 .0189 .0181 2214.07 745829
2009-11-25-17:24 2009-11-25-17:44 9764 .016 .0154 1877.34 679782
2009-11-25-17:44 2009-11-25-18:04 8812 .0167 .0163 1989.61 652405
2009-11-26-07:24 2009-11-26-07:43 8230 .0141 .014 1614.6 614051
2009-11-26-07:43 2009-11-26-08:04 11494 .0165 .0159 1833.1 785044
2009-11-26-08:04 2009-11-26-08:24 11028 .0182 .0172 1979.61 800688
2009-11-26-08:24 2009-11-26-08:44 10533 .0154 .0149 1734.62 750248
2009-11-26-08:44 2009-11-26-09:04 9367 .018 .0168 2043.95 685274
2009-11-26-09:04 2009-11-26-09:24 10307 .0214 .0201 2552.43 729938
2009-11-26-09:24 2009-11-26-09:45 10932 .0251 .0234 3111.48 762328
2009-11-26-09:45 2009-11-26-10:05 10992 .0278 .0254 3386.41 797404
2009-11-26-10:05 2009-11-26-10:24 10179 .0289 .0269 3597.24 764088
2009-11-26-10:24 2009-11-26-10:45 10216 .032 .0286 3879.47 681592
2009-11-26-10:45 2009-11-26-11:04 10277 .0286 .0263 3539.44 799219
2009-11-26-11:20 2009-11-26-11:23 1378 .0344 .0312 4261.62 688203
2009-11-26-11:23 2009-11-26-11:36 7598 .0299 .027 3675.36 805481
2009-11-26-11:36 2009-11-26-11:43 3345 .0298 .0272 3610.28 752625
2009-11-26-11:43 2009-11-26-12:03 10383 .0295 .0278 3708.36 728158
2009-11-26-12:03 2009-11-26-12:23 10322 .0332 .03 4002.33 745669
2009-11-26-12:23 2009-11-26-12:43 11847 .0316 .0292 3899.34 852273
2009-11-26-12:43 2009-11-26-13:03 10027 .0331 .0298 4030.5 722546
2009-11-26-13:03 2009-11-26-13:23 10130 .035 .0309 4199.08 730577
2009-11-26-13:23 2009-11-26-13:43 9783 .0331 .0306 4161.3 707915
2009-11-26-13:43 2009-11-26-14:03 10460 .0322 .0291 3947.63 753748
2009-11-26-14:03 2009-11-26-14:23 9452 .0333 .0309 4143.31 678283
2009-11-26-14:23 2009-11-26-14:43 9127 .0318 .03 4051.52 659341
2009-11-26-14:51 2009-11-26-15:03 5391 .0358 .0328 4358.58 652356
2009-11-26-15:03 2009-11-26-15:16 7183 .0425 .0348 4615.42 746824
2009-11-26-15:16 2009-11-26-15:23 2921 .0417 .0373 4887.75 682092
2009-11-26-15:23 2009-11-26-15:43 9597 .0393 .0352 4603.62 679656
2009-11-26-15:43 2009-11-26-16:03 8797 .0411 .0362 4783.66 630755
2009-11-26-16:03 2009-11-26-16:23 9957 .0453 .0391 5168.28 718100
2009-11-26-16:23 2009-11-26-16:43 11209 .0436 .0369 4870.77 808395
2009-11-26-16:43 2009-11-26-17:03 10729 .0428 .0375 5119.56 766103
2009-11-26-17:03 2009-11-26-17:23 9116 .0409 .0363 4912.58 659098
</pre>
GaoYuan
Edited by: user12194561 on Nov 26, 2009 7:34 PM

HR Logical Database PERAS

Hi,
HR Payroll we have developed Income Tax report created PDF and send email to Indiviual Employee. Now I am facing one problem while accessing following Code
Start of Selection
Get peras
End of Selection
SUBMIT rsconn01 WITH mode = c_int AND RETURN.
Get command failes for some employees and exit to submit command.
My query is how to find why program (GET PERAS) are not executing or how debug or put some error trap code for the same.
Thank
Yogesh

Hi Yogesh
As i can see you are using the PNPCE LDB. Generally you cannot know why few objects are not selected inside the GET PERAS event. If you want to debug this Please put a break point in Sub-routine PUT_PERAS in program SAPDBPNPCE which will tell you why exactly your few records are failing.
Regards
Ranganath

How to get current loop pass for LOGICAL DATABASE

HI,
can anyone tell me how to find the current loop pass in case of logical db.
As i have to put some condition when cursor goes to GET statement 2nd time..??
Mrunal

U need to explicitly handle this in the program.
START-OF-SELECTION.
DATA V_I TYPE I.
Get Event starts
GET PERAS.
V_I = V_I + 1.
IF v_i = 2.
*write the condition ...
ENDIF.
END-OF-SELECTION.

Payment Distribution to Artists by per user plays, rather than total plays

Hello!
I just had a thought about how payment is distributed to artists that I wanted to see if anyone might have some thoughts on. Spotify still does come under criticism on occasion for artist payment distribution - I've seen a couple of instances of people citing iTunes as providing more monetary compensation to artists since it is per download, rather than per play, among other things. This seems to be especially true for independent artists, and artists who are generally less well-known.
I was wondering if Spotify has ever considered doing payment distributions using the
sum[ (total artist streams per user) / (total streams per user) ] across all users
ratio for payment calculation, rather than the currently used
(total artist streams across Spotify) / (total streams across Spotify)
approach, i.e. calculating the artists' play ratio by user, rather than in one giant pool. If you have considered this, I would love to hear why the current payment implementation was chosen rather than a per user method, such as the one listed above. But...
If a per user method has not been considered by Spotify previously, I think it would be nice - while I'm not an analyst myself, I imagine that it could lead to more revenue for independent artists, and maybe even less famous artists that are still beholden to rights owners for distribution of payment. I think it would do this because it could account for differences in number of plays per user - rather than users who tend to play more music over the course of a month contributing more all artists' payout, each user has an equal voice in how money gets distributed to artists.
I understand that such a switch would be difficult, and possibly insurmountable in the instance of free users - so, I am positing this as an idea not for all users, but for Premium users only. With Premium, it is a feasible goal, since you have a finite number of plays, and a finite amount of money coming directly from that user, and do not have to worry about trying to calculate differences in advertisement impact for different users. Doing that ratio calculation would be relatively straightforward of a switch computationally (though quite a large change in the system nonetheless, of course).
I think this type of change would empower both users and artists to use Spotify more. Firstly, it would empower artists to allow Spotify to play their music because the metrics they would get per month would be more reflective of the size of their fan base, and how much importance that fan base puts on the artists' music than current metrics.
Secondly, it would empower users more, which I think is especially important for users between 18-32 years of age. While I am not an expert on the subject, I often find that users in this age group (my age group) care a great deal about having control over where their money ends up, which in this case means knowing which rights holders and/or artists are getting the money they are spending. I know I do. Switching to this system, while still not addressing the injustices that are felt within the relationship between rights holders and artists by many, would still allow users to have more of a say in who gets their money than the current system. On top of that, it might be helpfult for Spotify itself - if using Premium is the only way for users to feel empowered by knowing how their money is distributed, it may encourage people in the free tier to upgrade to Premium in order to feel empowered.
Just a thought. I'd love to hear what you and others have to say about this idea.

@Merik thanks for the warm welcome, and for the quick, informative response!
I had the chance to take a look at that page you linked to before my original post, and saw that paragraph you quoted, as well as the bullet point about paid users having a higher "per stream" rate. I guess what I was more interested in (and perhaps this is not the right place to ask this question?) was if there was more of an in-depth "why" behind their decision (and thanks again for linking to it!) documented anywhere that I might be able to read more about. Maybe I was missing something on that page (and please let me know if so!), but the only "why" that I could find was a sentence in the paragraph you quote above:
"We believe, however, that our service and the lives of artists will both be best if the World’s music fans enjoy more music than ever before in a legal, paid manner".
While it's great to see their opinion, I was more curious about the line of reasoning behind that position is all. Because I do wonder whether empowering premium users to have more fine-grained control over how their money is allocated, such as by doing pay "per user", might lead to both more paid users and more revenue for independent and/or lesser-known artists - and if that's something that Spotify has researched already, I would love to hear more about the pros and cons behind such an approach!
Thanks!

Get data from PNPCE LDB in ABAP hr

Hi all,
I am workng on ABAP Hr.In it I am using PNPCE LDB, when I
use GET PERNR statement it don't give any syntax problem but the selection screen does not generate due to GET PERNR statement.
Is there any Other statement to find the PERNR.
Points will be sured for valuable answers.
Thanks
Sanket sethi

A report that wants to use the PNPCE must enter this in its report attributes under Logical database.
In addition, the PERNR structure must be declared in the report using the 'TABLES PERNR' statement. You can only use the PERNR structure again in certain circumstances. The use of the 'GET PERNR' event is therefore forbidden. Instead, use the 'GET PERAS' event. Except for the PERNR-PERNR component, all other components of the PERNR structure are no longer filled and have initial values. This kind of programming (with the exception of PERNR-PERNR) therefore not permitted.
In addition to the 'GET PERAS' event, you can also use the GET PERSON' and 'GET GROUP' events. To be able to use these events, you must declare them using the NODES statement (NODES PERSON', 'NODES GROUP', or. NODES PERAS'.LdB's for HR are as follows:
PA----
PNP
Payroll----
PNPCE
Recruitment -
PAP
Orgmanagement -
PCH
PA report Example in attrubutes u have to add LDB is PNPCE
REPORT ZHR_TEST.
Type-Pools *
TYPE-POOLS : slis.
Nodes *
NODES: person,group,peras.
Tables *
TABLES: pernr,t512w,tfkbt,pa0022,pa0016,bkpf.
Infotypes *
INFOTYPES : 0000, "Actions
                     0001, "Org Details
                     0022, "Education Details
                     0041, "Date Specification
                     0002, "Personal Details
                     0016.
Internal Tables *
DATA :BEGIN OF t_output OCCURS 0,
           pernr TYPE pernr_d, " Personnel No.
           ename TYPE emnam, " Employee Name
           btrtl TYPE btrtl, "Personnel Subarea
           btext TYPE btext, "Personnel Subarea Text
           persk TYPE persk, "Grade
           ptext TYPE pktxt, "gradeText
END OF t_output.
DATA: t_fcat TYPE slis_t_fieldcat_alv.
ALV Variable
DATA : w_fieldcat TYPE slis_t_fieldcat_alv,
            wa_fieldcat TYPE slis_fieldcat_alv.
Event : GET Pernr *
GET peras.
PERFORM read_data. "Data Selection
Event : End-Of-Selection *
END-OF-SELECTION.
PERFORM f_addcat. "Field Cat
PERFORM f_display. "Display
*& Form read_data
FORM read_data.
*Organizational Assignment
rp_provide_from_last p0001 space pn-begda pn-endda.
IF pnp-sw-found EQ 1.
t_output-pernr = p0001-pernr.
t_output-ename = p0001-ename.
t_output-btrtl = p0001-btrtl.
t_output-persk = p0001-persk.
*Personal sub area text
SELECT SINGLE btext FROM t001p
INTO t_output-btext
WHERE btrtl = t_output-btrtl.
*Grade text
SELECT SINGLE ptext FROM t503t
INTO t_output-ptext
WHERE persk = t_output-persk AND
sprsl = 'EN'.
ENDIF.
APPEND t_output.
CLEAR t_output.
ENDFORM. "
*& Form f_addcat
FORM f_addcat .
*************Filling field catelog here.**************
*& Form f_display
FORM f_display.
*Local Variable
DATA : lv_repid LIKE sy-repid,
ls_layout TYPE slis_layout_alv.
lv_repid = sy-repid.
ls_layout-zebra = 'X'.
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
i_callback_program = lv_repid
is_layout = ls_layout
it_fieldcat = t_fcat
i_save = 'A'
TABLES
t_outtab = t_output
EXCEPTIONS
program_error = 1
OTHERS = 2.
IF sy-subrc 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
ENDFORM. " f_display

GET PERAS

Similar Messages

Maybe you are looking for