I have a questions regarding the Result Cache. In one of the snowflake documentation, It is given that to use the Result cache the Role has to be same even though Users are different. However when i tried with different Roles and User i was still able to access the Result Cache, Can you confirm my understanding - Any Roles that has access to the Object can reuse the result Cache though it is not same.
My Experiment:
User 1 with Role1 executed - select * from emp;
User 2 with Role2 executed the same query - select * from emp; It used fetched the result from Cache without using the Virtual Warehouse.
Per the Snowflake documentation, https://docs.snowflake.com/en/user-guide/querying-persisted-results.html#retrieval-optimization, most queries require that the role accessing result cache must have access to all underlying data that produced the result cache. The one exception noted is the SHOW command result cache can only be accessed using the same role. This may be the cause for the exception noted in the documentation that you've shared, although it is less clear.
The cache can not be served without any virtual Warehouse.
We require to compute (virtual Warehouse/cross virtual ) to process or preserve the cached data in there local disk.
"These are available across virtual warehouses, so query results returned to one user is available to any other user on the system who executes the same query, provided the underlying data has not changed."
for more detail link
Related
Is it ok to have multiple tenant QnA's to be stored in a single data source? for ex: in Azure Table Storage with all QnA's stored in a single table but each tenant data differentiated by an unique key and then filter results based on their unique key, this would help me to reduce the azure service cost but is their any drawbacks in using this method ?
Sharing a service/index in developer/test environments is fine, but there are additional concerns for production environments. These are some drawbacks, though you might not care about some of them:
competing queries: high traffic volume for one tenant can affect query latency/throughput for another tenant
harder to manage data for individual tenants: can you easily delete all documents for a particular tenant? Would the whole index need to be deleted or recreated for any reason which will affect all tenants?
flexibility in location: multiple services allow you to put data physically closer to where the queries will be issued. There can also be legal requirements for where data is stored.
susceptible to bugs/human error: people make mistakes; how bad is it to return data for the wrong tenant? How would you guard against that?
permission management: do you need to need grant permissions to view data for a subset of the tenants?
I am writing an application in C# that will execute queries against a local and linked databases (all Oracle 10g and newer), and I want to make sure I understand who is doing what when a linked database is being queried.
For example, for a simple query such as
SELECT * FROM FOO#DB_LINK
What is the local database server responsible for? I assume that this will use the CPU, disk, and memory on the database server that hosts DB_LINK, but what impact does this query have on the local database server resources?
What if the query is a little more complex, such as
SELECT * FROM FOO#DB_LINK F INNER JOIN BAR#DB_LINK B ON F.FOOBAR = B.FOOBAR
Is the entire query executed on the server that hosts DB_LINK, or is the INNER JOIN performed on the local server? If the INNER JOIN is performed by the local database, is it able to utilize the indexes that are on the linked tables (I wouldn't think so)? Is there a way to tell Oracle to execute the entire query on the linked database?
In my application, my queries will always be completely against either the local database, or a selected linked database. In other words, I will never have a query where I am getting data from both the local and a linked database at the same time like
SELECT * FROM FOO F INNER JOIN BAR#DB_LINK B ON F.FOOBAR = B.FOOBAR
To summarize,
I am only dealing with Oracle 10g or newer databases.
What is the local database server responsible for when a query (however complex) is strictly against linked tables?
What are the ways (if any) to optimize or give Oracle hints about how to best execute these kinds of queries? (examples in C# would be great)
Like most things related to the optimizer, it depends.
If you generate a query plan for a particular query, the query plan will tell you what if anything the local database is doing and which operations are being done on the remote database. Most likely, if statistics on the objects are reasonably accurate and the query references only objects in a single remote database, the optimizer will be smart enough to push the entire query to the remote server to execute.
Alas, the optimizer is not always going to be smart enough to do the right thing. If that happens, you can most likely resolve it by adding an appropriate driving_site hint to the query.
SELECT /*+ driving_site(F) */ *
FROM FOO#DB_LINK F
INNER JOIN BAR#DB_LINK B
ON F.FOOBAR = B.FOOBAR
Depending on how complex the queries are, how difficult it is to add hints to your queries, and how much difficulty you have in your environment getting the optimizer to behave, creating views in the remote database can be another way to force queries to run on the remote database. If you create a view on db_link that joins the two tables together and query that view over the database link, that will (in my experience) always force the execution to happen on the remote database where the view is defined. I wouldn't expect this option to be needed given the fact that you aren't mixing local and remote objects but I include it for completeness.
A 100% remote query will get optimized by the remote instance. The local instance will still need to allocate some memory and use CPU in order to fetch results from the remote server but the main work (things like hash joins and looping) will all be done by the remote instance.
When this happens, you will get a note in your local execution plan
Note
-----
- fully remote statement
As soon as something is required to be done on the local server (e.g an insert or if you join to a local table (including local dual)) as part of the statement, then the query becomes distributed, only one server can be considered the driving site and it will typically be local (I can't come up with a demo where this chooses the remote site, even when it's cheaper so maybe it's not cost based). Typically this will end up with you hitting some badness somewhere - perhaps a nested loop join against remote tables computed on the local side.
One thing to keep in mind with distributed queries - the optimizing instance will not look at histogram information from the other instance.
Questions
Does the user option preload refer to caching on the client or on the server?
Are there any ways to make this occur asynchronously so that users don't take a large performance hit when first requesting data from a table?
More Info
In Dynamics Ax 2012, under File > User Options > Preload a user can select which tables are preloaded the first time they're accessed.
I've not found anything to say whether this behaviour relates to caching on the client or the AOS.
The fact it's a user setting implies that it's the client.
But it could be an AOS setting where users with this option take the initial hit of preloading the entire table, whilst those without would benefit from any caching caused by other users, but wouldn't trigger the load themselves.
If it's the latter we could improve performance by removing this option from all (human) users, leaving it enabled only on our batch user account, having scheduled jobs on each AOS to request a record from each table, thus triggering the preload without any user being negatively impacted.
Ref: http://dynamicbusinesssolutions.ru/axshared.en/html/9cd36702-2fa7-470c-a627-08
If a table is large or frequently changed it is not a candidate for entire table cache. This applies to ordinary users and batch users alike.
The EntireTable cache is located on the server, but the load is initiated by the user, the first user doing the select takes a performance hit.
To succesfully disable a table from preload, you can disable it using the Admin user, it will apply to all users. Or you can let all users disable it by themselves.
Personally I never change the user setup. If a table is large I change the table CacheLookup property as a customization.
See Set-based Caching:
When you set a table's CacheLookup property to EntireTable, all the
records in the table are placed in the cache after the first select.
This type of caching follows the rules of single record caching. This
means that the SELECT statement WHERE clause must include equality
tests on all fields of the unique index that is defined in the table's
PrimaryIndex property.
The EntireTable cache is located on the server
and is shared by all connections to the Application Object Server
(AOS). If a select is made on the client tier to a table that is
EntireTable cached, it first looks in its own cache and then searches
the server-side EntireTable cache.
An EntireTable cache is created for
each table for a given company. If you have two selects on the same
table for different companies the entire table is cached twice.
Note: Avoid using EntireTable caches for large tables because once
the cache size reaches 128 KB the cache is moved from memory to disk.
A disk search is much slower than an in-memory search.
Using the Auth Manager of Yii I used CachedDbAuthManager. Once SQL executes for specific role against a user it caches the result. Next time records fetched from cache. Now once admin delete the role for a particular user it still remains in cache.
What is solution to this Problem?
Have a look at Yii's Cache Dependency Implementation.
You could eg. invalidate a cache when the admin edits an auth table, see also the database cache dependency. Often this is done just by looking for the latest eg. modified_at time, but this column is not part of the standard auth tables.
From the database cache man page:
CDbCacheDependency represents a dependency based on the query result of a SQL statement.
There is another extension SingleDbAuthManager which is doing nearly the same thing. It reads whole auth tree at once and cache it.
The performance of both SingleDbAuthManager and CachedDbAuthManager is vering. CachedDbAuthManager taking less time but fails to update cache in my case.
I have a user object represented in JPA which has specific sub-types. Eg, think of User and then a subclass Admin, and another subclass Power User.
Let's say I have 100k users. I have successfully implemented the second level cache using Ehcache in order to increase performance and have validated that it's working.
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-cache
I know it does work (ie, you load the object from the cache rather than invoke an sql query) when you call the load method. I've verified this via logging at the hibernate level and also verifying that it's quicker.
However, I actually want to select a subset of all the users...for example, let's say I want to do a count of how many Power Users there are.
Furthermore, my users have an associated ZipCode object...the ZipCode objects are also second level cached...what I'd like to do is actually be able to ask queries like...how many Power Users do i have in New York state...
However, my question is...how do i write a query to do this that will hit the second level cache and not the database. Note that my second level cache is configured to be read/write...so as new users are added to the system they should automatically be added to the cache...also...note that I have investigated the Query cache briefly but I'm not sure it's applicable as this is for queries that are run multiple times...my problem is more a case of...the data should be in the second level cache anyway so what do I have to do so that the database doesn't get hit when I write my query.
cheers,
Brian
(...) the data should be in the second level cache anyway so what do I have to do so that the database doesn't get hit when I write my query.
If the entities returned by your query are cached, have a look at Query#iterate(). This will trigger a first query to retrieve a list of IDs and then subsequent queries for each ID... that would hit the L2 cache.