The following video demonstrates how to monitor sql queries done by EF in an MVC application:
http://channel9.msdn.com/Series/Implementing-Entity-Framework-with-MVC/01
They recommend glimpse for mvc5:
https://www.nuget.org/packages/Glimpse.Mvc5/
I can not find glimpse for Azure mobile services so what is the best way to monitor sql queries in Azure mobile services?
Open Azure Management Portal for your Database, login and open performance tab.
There you get some basic monitoring data about your queries.
You can query sys.dm_exec_query_stats table in your database too, to create custom reports about your queries.
If you don't mind third-party services, look into CloudMonix # http://cloudmonix.com - it has special support for SQL Azure and a free plan.
When monitoring SQL Azure databases, it will show you top 10 queries, connections, logs, performance characteristics and allow you to create your own SQL-based metrics.
Disclaimer: I'm affiliated with the product
Related
it's been 2 months I'm working for a new client on BI Reporting on Oracle BI Publisher within an OracleCloud CRM and HCM. to make query to OracleCloud database I have to use notepad++ and then copy/past my query in the Query textArea on BIPublisher (which is a simple text area without any syntaxe check or color), I was wondering if there are some experts who might know a way to connect SQL Developer to OracleCloud database so I can run my queries directly without copy/past on the browser.
thank you a lot
There's no direct access to the underlying Oracle Database from your SaaS subscription.
We (the SQL Developer team) are working with a few of the SaaS business owners to make SQL Developer Web available for their subscribers. This would allow you to run queries directly against your database w/o having to do the copy/paste jump you're doing today in BI Publisher.
I cannot provide guidance on when this will happen or even if your particular services will make it available.
The TL;DR answer to your question is 'No, but we are working on it'
I host my database on Azure. I would like to search data on the table in that database. I am trying to use B4I and the tech help their said I need to use REST API's. I am pretty sure I need to use ODATA. I have the auth token but I am not sure if this is even possible.
In order to query Azure SQL with an API you need to add a layer between it and the destination. As mentioned in this question, OData is a specification that can be implemented fairly easily as there are plenty of libraries that will take care of the bulk of the code for you.
As far as where to host the API, you have several options within Azure. The most common being App Services, Azure Functions, and Logic Apps.
I'm very new in the world of "NoSQL", Recently I started using Cosmos DB for JSON documents and am able to store and get data using CosmosDB "SQL" and "Mongo" API.
Which API is best for me? (requirement: Performance, Low Latency, Huge Collection, Low cost)
Now I have spent more than 6 months with Cosmos DB project. I can give my opinion on this question.
Azure Cosmos DB offer the same feature with SQL API vs Mongo API, hence you can't compare by feature.
Reason using Mongo API in Cosmos DB
If you have existing Mongo DB database and you want to migrate on Azure.
If you or your team members have Mongo DB experience.
If you are developing cloud agnostic application, you can move your application on-premise or any other cloud vendor.
Reason using SQL API in Cosmos DB
If you have SQL query experience, it would be easy to start.
If you are not looking cloud agnostic application. (can't move Cosmos DB application on-premise or other clouds vendors).
Cosmos DB Change Feed only available with SQL API.
--- UPDATED 2020 ---
Change Feed is available for all the APIs across all available SDKs except the Table API
Both the API’s provide you high throughput, low latency, elastic scale, geo-replication, etc.
It boils down to what you are comfortable with. Many people preferred Mongo, as they are already familiar with Mongo, it’s syntax, tools, and they already had an application built on Mongo which they migrated to CosmosDB.
If you are starting new, and don’t have an existing investment in Mongo, I will suggest starting with SQL. SQL is the oldest API of CosmosDB, and more battle hardened.
As a software engineer using MongoDB API. I can confirm that my team and I suffered when handling 426 code errors from CosmosDB. So we end up developing our own custom solution with Polly to handles these throttles. Whereas if we used SQL API we would have access to CosmosDB sdk which pretty much handles these situations. This is just my feedback.
I am developing a c# web application that will be hosted in Windows Azure and use Table Data Storage (TDS).
I want to architect my application such that I can also (as an option) deploy the application to a traditional IIS server with some other NoSql back-end. Basically, I want to give my customers the option to either pay me in the software as a service model, OR purchase a license of my application that they can install on a (non-azure) production server of their own.
How can I best architect my data layer and middle tier to achieve both goals?
I will likely need a Windows Azure Worker Role and an Azure Queue. How complicated is to replicate these? Can I substitue a custom Windows Service and some other queuing technology?
How I can the entities in my data model be written such that I can deploy to Azure TDS or some other storage when not deploying to Azure? Would MongoDB or similar be useful for this?
Surely there is a way to architect for Azure without being married to it.
I will likely need a Windows Azure Worker Role and an Azure Queue. How complicated is to replicate these? Can I substitue a custom Windows Service and some other queuing technology?
Yes - a Windows service with some other queuing technology would fit this reasonably well - and worker roles have a main/Run loop which is easy to use within a Windows Service.
How I can the entities in my data model be written such that I can deploy to Azure TDS or some other storage when not deploying to Azure? Would MongoDB or similar be useful for this?
NoSql is a general term encapsulating lots of different technologies. I think Azure TDS currently belongs to the Key-Value store family of NoSql, while MongoDB is more of a document database offering much richer functionality than TDS - see http://en.wikipedia.org/wiki/NoSQL_(concept). For mimmicking Azure TDS I think maybe a variant of something like Redis might work (although I believe Redis itself has wider functionality then TDS currently)
In general, it depends on the shape of your data, but I suspect if you can fit it in Azure TDS, then you'll be able to fit it into your choice of other storage too.
Surely there is a way to architect for Azure without being married to it.
Yes - as you've suggested in your question, you can architect your app so it can work on other technologies instead. In fact, this is quite a similar challenge to the traditional SQL data abstraction methods. However, I think there are a few places where you'll find TDS pushing you in certain
directions which won't fit well with other stores - e.g. Azure pushes you much more towards data replication; has very specific rules on keys; offers high performance using very specific mechanisms; and offers limited transaction integrity in very specific situations. These factors may mean that you do have to indeed change some middle tier layers as well as some data layers in order to get the most out of your app in both its Azure and non-Azure variations.
One other thought - It might be easier to offer your clients a multitenant SaaS version on Azure, and a singletenant version hosted on Azure - but this does depend on the clients!
I found a viable solution. I found that I can use EF Code First with SQL Server or SQL CE if I design my entities with the same PartitionKey & RowKey compound key structure that Azure Table Storage requires.
With a little help from Lokad Cloud (http://code.google.com/p/lokad-cloud/) to perform the interaction with Azure Table Storage, I was able to craft a common DataContext that provides crud operations against either EF's DbContext OR Lokad's TableStorageProvider.
I even found a nice way to manage relationships between entities and lazy-load them properly.
The solution is a bit complex and needs more testing. I will blog about it and post the link here when ready.
I'm starting on some architecture work for a .Net based social networking application to be hosted on Azure cloud. we are going to be using ASP.NET MVC on the front end.
i would like to consider the options for storage. considering scalability needs and due to the inter-connected nature of the application, SQL azure has been ruled out.
what would be the main considerations in choosing a graph DB such as Sones GraphDB or neo4j which have features specific for a social networking application against using windows azure table storage to achieve the needs.
i'm mostly concerned about development time, cost, ability to leverage existing skills like .NET and reliability of the graph DB platforms and ease of setup and administration.
Graph databases are designed for applications such as social networks. For ease of development, it may be best to start with something like GraphDB. A key advantage over a key-value database is powerful query and traversal capabilities. It would be easy to, for instance, find all occurrences of friends of friends using the GraphDB query syntax.
The benefit of a key-value database service like Azure Table is low cost, minimal administrative overhead and scalability. You can store 500TB of data per Azure storage account and setup accounts in multiple regions. There is no server setup or database administration overhead and the Visual Studio SDK is easy to use. The down side is that graph like query support is not built in and you must index off the Primary Key / Row Key pair. For additional Azure Table design pattern please see https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/