Queries in production

Hi Guru,
We have some queries in production. But there are couple of them which other users cannot able to see or not available. Only I can see on my PC. They all have the same rights or roles as I do. i.e. fullcontrol. any suggestion please.
thank You

Hello Amit,
When you say the users are not able to see the queries, I am assuming the workbooks. Since, this happens a lot in a system when a workbook has changed and has been transported over the id associated with the workbook changes due to which the authorization doesn't work any more and they are not assigned to any role.
In order to avoid this please run the program "RSWB_ROLES_REORG" to first identify all the corrupted workbooks (if my assumption is correct).
Then you can either assign them to a role and before that make sure the right id is assigned to the role.
Also refer to the OSS Note 385219 for additional information in this regards.
Please assign the points if this answers your issue else let me know additional details.
Thanks
Dharma.

Similar Messages

Deleting Queries in Production system

Hello,
I transports few queries into production system but I would like to delete those queries
Can i just delete in production or is there any procedure?
These queries are just brand new queries.
Thanks,

What is the difference between "Create Transport Requests for BEx " and "Transport object"
When do we use "Create Transport Requests for BEx "?
When do we use "Transport object"?
Correct answer = points
Thanks,
Edited by: Moderator on Jan 30, 2008 3:41 PM
*Everyone on the forum knows that points will be assigned for correct and useful replies. There is really no need to keep mentioning this on each post you create. Thanks!

Queries in Production for Business Users

Hello fellow SAP Security Colleagues,
I am familiar with some of the obvious reasons why query development and execution should be restricted in production and have generally agreed with the restrictions.
However, I wanted to reach out to those of you who have supported a project which either:
     A.) allowed business users to create and execute queries in production /or/
     B.) allowed queries to be developed and transported to production for use by business users.
I would like more information on how this is working out for your company and what steps you are taking to make it work securely and with little performance issues.
Thank you so much for your feedback!
Edited by: Teresa Lansberry on Feb 5, 2009 3:46 PM
Edited by: Teresa Lansberry on Feb 5, 2009 3:47 PM
Edited by: Teresa Lansberry on Feb 5, 2009 3:48 PM

Hi Teresa,
I agree with Julius and Auke, but have a fair amount of experience of working with companies who disagree....
At my current client we have a small project taking place to rationalise the use of queries.
Until recently almost all users had the access to create and change queries in the production environment. There are approximately 3000 queries and 1500 infosets used, created, 50% of which are used over the previous 12 months. The result of this is that many reporting controls are bypassed and there are many "versions of the truth".
For legal reasons we now need to secure the data. This also requires robust change control over the queries. The existing queries were transported into the development environment and access to maintain queries has been removed in Prod.
All new queries are created by a functional expert and then handed over to the development team. The dev team review the query (make sure that it is reasonably efficient etc) and then put in auth checks into the infoset. This is then tested and only when signed off, is transported into the Prod.
It's not an ideal situation but until most of the reporting has been moved to BI, is reasonably controlled. What it rarely addresses is the need for consistent reporting.

Developing Queries in Production

My client insist on developing and testing queries in their production system. The were told that this was the best option. I disagree.
I come from an R/3 background and have never heard of such a thing. Their reasoning is that the transports never worked.
Can someone help me with some additional reasons why this should not be allowed other than the obvious.
Thanks

I have been an advocate of permitting creation of Adhoc queries in production. We all must keep in mind that R3 is a transactional system whereas BW is a data warehouse.
What is the use of a data warehouse if you cannot obtain Adhoc reports, as the name implies, in production, on the fly, without going through an IT QA and transport process. Most of the improvements occur with Super Users and functional administrators improving the processes and queries to fit the needs of the users. How would a super user see changed conditional and exception reporting, if he does not have access to do it?
That said, the best practices I have seen include a routine process to eliminate / delete very old redundant queries created by users in Production. The organization does need trained users to do such an activity. All critical and significant queries should get duplicated and transported through Development, and not be changed in Production environment. Only such queries should get placed in roles. Access to infoareas should be limited to Super users. Global structures should be used and available to be modified after they are copied using save as function.
I am aware of the down sides on maintainance and performance, when you permit such a process. Still, the benefits are much more to an enterprise, to ignore such an option.
Sunil Aghi

Best Practice on Creating Queries in Production

We are a fairly new BI installation. I'm interested in the approach other installations take to creation of queries in the production environment. Is it standard to create most queries directly into the production system? Or is it standard to develop the queries in the development system and transport them through to production?

Hi,
Best practices applied to all developments whether it is R/3, BI modelling or Reporting and as per the best practice we do development in Development system, testing in testing box and finally deploy successful development to production. yes for user analysis purpose, user can do adhoc analysis or in some scenario they create user specific custom queries (sometimes reffere as X-query created by super user).
So it is always to do all yr developement in Development Box and then transport to Production after successful QA testing.
Dev

How to create a transport for queries from production system

We have a situation where the production client has been open during cutover and a user has modified queries which were previously transported into production from our development system. We now wish to 'synchronise' our systems so production can be closed (although we will use the changeability options to allow maintenance of local queries).
Does anyone have experience of this problem? What is the best way of exporting the queries in such a way that we can import them into our development and quality systems?
As ever, any suggestions will be gratefully received.

Hi,
In similar situation, we opted for manual modifications in the Dev. We made the changes in the queries as they were in Prod and then transported them from Dev to Q and then to Prod.
This is how generally it is done.
Regards,
Yogesh

Copy/Create local copy queries in Production

We´ve closed our Production environment for changes.
The problem is that some users must have access to copy queries/workbooks (that were transported from DEV) to a local copy ($TMP), in order to make changes to the structure of these copied queries. It seems that when we click on "Save query as", BW tries to save it into a Request, but it should save it as Local.....
How could it be achieved?
Thank you in advance,
Cris

Use Tcode SU53 & then try creating/changing a query...The Authorization Object required for creating/changing a query is captured in SU53 screen.
Authorizations are based on the values set for an Authorization Object.
For Eg : If a value '01' is set against an Authorization Object it means that a Create Authorization is available.Like value '02' for change etc..,
Get this authorization object with the necessary authorizations assigned to a role & have it assigned to the Users.

Transport of queries from production to developement

Hello BI Community,
We allow ad-hoc query development in our production system. Yet certain queries are critical and must be "certified" so that they cannot be overwritten in an ad-hoc manner.
The method for certifying a query is to transport it from the development system, and once done the only way to change this query is to move another transport.
As more and more sophisticated queries need to be certified, it is becoming difficult to re-create those queries in the development system for the certification process.
Does anybody have experience or recommendations around moving a query that was originally created in the production system BACKWARDS to the development system ? Then it would be easy to move forward again via transport for certification.
Thank you !
Kiran

Hi Kiran,
1. Open production system
2. Create transport (1) in Prod, add queries, process chains, etc.
3. Create new transport (2) in Prod (in SE01) of type "Transport of Copies"
4. Enter your target system on this screen (choose your Dev system here!)
5. Include objects from transport 1 into transport 2
6. Release transport 2 to go to Dev
7. Delete transport 1 from Prod. This release locks on the objects.
8. Close Prod
8. Import transport 2 into Dev system
OR
The reverse transport is usually not setup , what you could do is :
1. As BASIS to set up the connection
2. Copy the transport object into file and then import it manually into Development
Check this thread.............also.....
Re: Reg : Transport req
Regards,
Vijay.

Queries about Production Support

Hi Experts,
Can some one please explain about the Support / Production / Maintenance project activities?
1. What could be the responsibilities of XI developer in Production Support?
2. Explain about... what is Level 1, Level 2, Level 3 support? XI developer role will be responsible for which Level of support (Level 1/2/3)
3. Can you please mention some common or real or usual issues or errors need to be encountered / need to troubleshoot?
Thanks in advance.
Shriya

Hi
>>>>3. Can you please mention some common or real or usual issues or errors need to be encountered / need to troubleshoot?
/people/prashanth.azharuddin/blog/2006/11/24/some-errors-in-an-xi-production-environment
>>1. What could be the responsibilities of XI developer in Production Support?
https://forums.sdn.sap.com/click.jspa?searchID=2268712&messageID=3060961
https://forums.sdn.sap.com/click.jspa?searchID=2268712&messageID=3016400
Role of XI support person

Queries inactive in Production Technical name is not coming After Transport

Hi Folks,
i transported queries with role into production .
There queries are coming without their technical name means b'coze its related data-target was not active but now its active even then queries are not coming with their technical name.
So can we do any manual activation in production or should i go for re-import the same req again into production.
Plz Suggest me

Hi Rajan,
You can do manual activation in production and you can change the technical names of your queries in production.
Thanks and Kind Regards,
Lakshman Kumar Ghattamaneni

Error when generating the report in Production Server

Hi,
I have created one infoset query in Development server of my client. It is working fine there. I had transported the request containg this query to Production server. But whenever I am trying to generate report using this query in Production server it is giving an error message
"Error when generating the report".
I am not getting what 's problem.
Samriddhi

Samriddhi,
Genarally its not suggested to transport Queries. Should be able to create Queries directly Production. There might be diferences between your Development and Production versions.
Thanks.

Queries Published to Workbook Roles

Hello Gurus,
I need some advice on this particular situation.
I currently have users in our BI systems (BI 7.0) that are assigned to roles specifically for workbooks to use with the BEX analyzer. In this case there are users who can publish queries to workbooks for anyone to use (as long as they're assigned to the workbook role).
Note: To be specific, our business users do not create queries in production, but simply create a view of an existing query and make changes based on their specific need, which then can be saved to a workbook.
In the past we had workbook roles transported (in error) to production from development, which overwritten the queries published to the workbook in production. Updates to the workbook roles were only being made in production, so when the roles came over from DEV it wiped the queries that were created by the end users. Iu2019m currently in the process on re-structuring the role authorization concept in our BI system and would like to incorporate workbook authorization to one role (role based security) instead of having multiple on-off roles for workbooks. Having one role means Iu2019ll need to work in DEV and push the changes to production, however with the workbook situation if any queries have been published to the one role it will be wiped every time a transport goes into production.
I would like to the following:
1. Is there an alternative method to running queries without utilizing workbooks?
2. What would be the best scenario or best practice when publishing queries to workbook roles?
Regards,
Wes

Wes:
User cannot see favorites of another user in BEx Analyzer.
Instead of saving a workbook to the role and risk having it overwritten the next time the role is transported, your users could save their changes as a view ('save view global' option). They will not be prompted to save as a favorite or in a role - it inherits whatever role the query is in and will not be overwritten if that role is transported.
Keep in mind that things like query properties set in the view are not retained like they are with a workbook, however. The view stores the navigation state, variable values, etc.
Hope this helps...
Regards,
Kerry

Archive created for the report in Production server

Hi experts
I have developed a report to create sales orders. The report was working fine in quality, after transfering to the production some archive is getting created and it is occupying a lot of space. Could u tell me what is this archive and how can I rectify this bug.
Thanks
Gaurav

Samriddhi,
Genarally its not suggested to transport Queries. Should be able to create Queries directly Production. There might be diferences between your Development and Production versions.
Thanks.

Warehouse partitioning - performance of queries across multiple partitions?

Hi,
We are using Oracle 11.2.0.3 and have a large central fact table with several surrogate ids which have bitmap indexes on them and have fks looking at dimension tables + several measures
(PRODUCT_ID,
CUSTOMER_ID,
DAY_ID,
TRANS_TYPE_ID,
REGION_ID,
QTY
VALUE)
We have 2 distinct sets of queries users look to run for most part, ones accessing all transactions for products regradless of the time those transactions happened (i.e. non-financial queries - about 70%,
queries determining what happened in a particular week - 20% of queries.
Table will have approx 4bn rows in eventually.
Considering adding extra column to this DATE and range partition this to allow us to drop old partitions every year - however this data wouldn't be joined to any other table.
Then considering sub-partitioning by hash of product_id which is surrogate key for product dimension.
Thoughts on performance?
Queries by their nature would hit several sub-partitions.
Thoughts on query performance of queries which access several sub-partitions/partitions versus queries running aganist a single table.
Any other thoughts on partitioning strategy in our situation much apprecaited.
Thanks

>
Thoughts on query performance of queries which access several sub-partitions/partitions versus queries running aganist a single table.
>
Queries that access multiple partitions can improve performance for two use cases: 1) only a subset of the entire table is needed and 2) if the access is done in parallel.
Even if 9 of 10 partitions are needed that can still be better than scanning a single table containing all of the data. And when there is a logical partitioning key (transaction date) that matches typical query predicate conditions then you can get guaranteed benefits by limiting a query to only 1 (or a small number) partition when an index on a single table might not get used at all.
Conversely, if all table data is needed (perhaps there is no good partition key) and parallel option is not available then I wouldn't expect any performance benefit for either single table or partitioning.
You don't mention if you have licensed the parallel option.
>
Any other thoughts on partitioning strategy in our situation much apprecaited.
>
You provide some confusing information. On the one hand you say that 70% of your queries are
>
ones accessing all transactions for products regradless of the time those transactions happened
>
But then you add that you are
>
Considering adding extra column to this DATE and range partition this to allow us to drop old partitions every year
>
How can you drop old partitions every year if 70% of the queries need product data 'regardless of the time those transactions happened'?
What is the actual 'datetime' requirement'? And what is your definition of 'a particular week'? Does a week cross Month and Year boundaries? Does the requirement include MONTHLY, QUARTERLY or ANNUAL reporting?
Those 'boundary' requirements (and the online/offline need) are critical inputs to the best partitioning strategy. A MONTHLY partitioning strategy means that for some weeks two partitions are needed. A weekly partitioning strategy means that for some months two partitions are needed. Which queries are run more frequently weekly or monthly?
Why did you mention sub-partitioning? What benefit do you expect or what problem are you trying to address? And why hash? Hash partitioning guarantees that ALL partitions will be needed for predicate-based queries since Oracle can't prune partitions when it evaluates execution plans.
The biggest performance benefit of partitioning is when the partition keys used have a high correspondence with the filter predicates used in the queries that you run.
Contrarily the biggest management benefit of partitioning is when you can use interval partitioning to automate the creation of new partitions (and subpartitions if used) based solely on the data.
The other big consideration for partitioning, for both performance and management, is the use of global versus local indexes. WIth global indexes (e.g. a global primary key) you can't just drop a partition in isolation; the global primary key needs to be maintained by deleting the corresponding index entries.
On the other hand if your partition key includes the primary key column(s) then you can use a local index for the primary key. Then partition maintenance (drop, exchange) is very efficient.

Deleting query in production server

Hi,
Some of the duplicate queries are deleted in Development server, which are not transported to other servers by some mistakes.
Now we need to delete those duplicate queries in production server.
Plsease suggest immediately.
Regards,
Archana

Hi,
use the Tcode RSZDELETE.
If you dont have authorization use the program COMPONENT_REORG.
Regds,
Shashank

Queries in production

Similar Messages

Maybe you are looking for