Dukungan SQL Server 2016 Untuk Transaksi Terdistribusi

Dukungan SQL Server 2016 Untuk Transaksi Terdistribusi Dengan AlwaysOn Ketersediaan Grup

Dukungan SQL Server 2016 Untuk Transaksi Terdistribusi dengan Selalu Aktif Ketersediaan Grup terdengar sangat menjanjikan. Mereka memang melakukan beberapa perbaikan dalam hal itu, tetapi belum sepenuhnya didukung. Contoh Sumber Transaksi Bagikan – Dukungan DTC SQL Server 2016 Pada Kelompok Ketersediaan [/ caption] Dukungan SQL Server 2016 Untuk Transaksi Terdistribusi hanya didukung jika transaksi didistribusikan di beberapa contoh SQL Server. Ini TIDAK didukung jika transaksi didistribusikan antara database yang berbeda dalam contoh yang sama dari SQL Server. Jadi dalam gambar di atas, jika database berada pada contoh SQL yang terpisah itu akan bekerja. Tetapi tidak jika database berada pada contoh yang sama yang lebih mungkin. Jika Anda memerlukan dukungan transaksi terdistribusi antara database yang berbeda dalam contoh SQL Server yang sama dan Anda ingin ketersediaan tinggi, Anda masih harus menggunakan SQL Server Always On Failover Cluster tradisional atau Cluster SANLess menggunakan DataKeeper. Direproduksi dengan izin dari Clusteringformeremortals.com

Cara Mengganti Ketersediaan Set Tersedia dari Azure VM yang Ada

Mengubah Set Ketersediaan Dari Sebuah Azure VM yang Sudah Ada

6/21/2016 – Pembaruan. Karena saya memposting artikel ini saya telah diberitahu oleh sumber yang dapat dipercaya bahwa ada skrip PowerShell yang lebih baru yang dapat Mengubah Kumpulan Ketersediaan Dari Azure VM yang Ada, bahkan lebih andal. Saya belum mencobanya. Tapi saya percaya sumber dan Dukungan Microsoft Premiere mengarahkannya ke artikel ini. https://gallery.technet.microsoft.com/Azure-RM-Availability-Set-39e19d01 Saya sedikit terkejut mengetahui hari ini bahwa tidak mudah untuk mengubah apa yang Tersedia Set VM berada dalam sekali sudah dibuat. Portal Azure tidak memiliki mekanisme penambahan VM yang ada ke Kumpulan Ketersediaan. Untungnya bagi saya, saya menemukan sumber daya yang hebat ini. Atur Azure Resource Manager VM AvailabilitySet Dengan memanfaatkan skrip PowerShell yang tersedia untuk diunduh di artikel itu, saya dapat menambahkan dua VM yang sudah ada ke yang telah saya buat. Akhirnya saya bisa Mengganti Ketersediaan Set Dari Existing Azure VM – apa yang hidup hemat!

Menyebarkan kluster Failover SQL Server di Azure Resource Manager

Menyebarkan Microsoft SQL Server 2014 Failover Cluster di Azure Resource Manager

Dalam posting ini, kita akan detail langkah-langkah spesifik yang diperlukan untuk Menyebarkan SQL Server Failover Cluster di Azure Resource Manager. Saya akan menganggap Anda akrab dengan konsep Azure dasar serta konsep SQL Server Failover Cluster dasar. Menerapkan 2-node SQL Server Failover Cluster di satu wilayah Azure menggunakan Azure Resource Manager bukanlah ilmu roket. Apa yang saya akan fokus dalam artikel ini adalah keunikan tentang penggelaran Cluster Failover SQL Server di Azure Resource Manager. Jika Anda masih menggunakan Azure Classic dan perlu menggunakan SQL Server Failover Cluster di Classic, baca artikel saya “LANGKAH-LANGKAH-LANGKAH: BAGAIMANA MENGONFIGURASI SQL SERVER FAILOVER CLUSTER INSTANCE (FCI) DI MICROSOFT AZURE IAAS #SQLSERVER #AZURE # SANLESS ”Sebelum kita mulai, mari kita membiasakan dengan Artikel Windows Azure, ketersediaan tinggi dan pemulihan bencana untuk SQL Server di Azure Virtual Machines. Dalam artikel itu semua opsi HA diuraikan. Ini termasuk AlwaysOn AG, Pencerminan Database, Pengiriman Log, Pencadangan dan Pemulihan, dan akhirnya Failover Cluster Instances. Dengan asumsi Anda telah menolak opsi-opsi lain karena biaya yang terkait dengan Edisi Enterprise SQL Server atau kurangnya fitur, kami berfokus pada opsi terakhir – SQL Server AlwaysOn Failover Cluster Instance (FCI). Ketika Anda membaca artikel itu menjadi jelas bahwa kurangnya penyimpanan bersama yang sadar cluster di Azure adalah kendala dalam menyebarkan gugus Failover SQL Server. Namun, ada beberapa alternatif yang dijelaskan dalam artikel itu. Kami akan fokus menggunakan SIOS DataKeeper, untuk menyediakan penyimpanan yang akan digunakan dalam klaster. Gambar 1 Kebijakan dukungan Microsoft untuk SQL Server Failover Cluster https://azure.microsoft.com/en-us/documentation/articles/virtual-machines- windows-classic-sql-dr / [/ caption] Dengan DataKeeper Cluster Edition Anda dapat mengambil penyimpanan yang terhubung secara lokal, apakah itu Disk Premium atau Standar, dan mereplikasi disk tersebut secara serentak, asinkron atau campuran atau keduanya, antara dua atau lebih banyak node klaster. Selain itu, sumber daya DataKeeper Volume terdaftar di Windows Server Failover Clustering yang mengambil tempat dari sumber Disk fisik. Alih-alih mengontrol pemesanan SCSI-3 seperti Physical Disk Resource, Volume DataKeeper mengontrol arah cermin, memastikan node aktif selalu menjadi sumber cermin. Sejauh SQL Server dan Failover Clustering yang bersangkutan, terlihat, terasa dan bau seperti Disk Fisik dan digunakan dengan cara yang sama Sumber Daya Disk Fisik akan digunakan.

Pra-syarat Untuk Menyebarkan SQL Server Failover Cluster Di Azure Resource Manager

• Anda telah menggunakan Portal Azure sebelumnya dan nyaman menggunakan mesin virtual di Azure IaaS.
• Telah memperoleh lisensi atau lisensi eval dari SIOS DataKeeper
• Apakah akrab dengan SQL Server AlwaysOn Failover Cluster Instance. Jika tidak, silakan tinjau dokumentasi di sini https://msdn.microsoft.com/en-us/library/ms189134.aspx

Cara Mudah Untuk Melakukan Proof-Of-Concept

Jika Anda terbiasa dengan Azure Resource Manager, Anda tahu salah satu fitur baru yang hebat adalah kemampuan untuk menggunakan Template Penerapan untuk menyebarkan aplikasi dengan cepat yang terdiri dari sumber daya Azure yang saling terkait. Banyak dari template ini dikembangkan oleh Microsoft dan sudah tersedia di komunitas mereka di Github sebagai "Template Quickstart". Anggota komunitas juga bebas memperpanjang templat atau mempublikasikan templat mereka sendiri di GitHub. Salah satu template yang berjudul "SQL Server 2014 AlwaysOn Failover Cluster Instance dengan SIOS DataKeeper Azure Deployment Template" yang diterbitkan oleh SIOS Technology sepenuhnya mengotomatiskan proses penyebaran 2-node SQL Server FCI ke dalam Domain Direktori Aktif baru. Untuk menerapkan templat ini semudah mengklik tombol “Deploy to Azure” di template. Gambar 2- Kunjungi https://github.com/SIOSDataKeeper/SIOSDataKeeper-SQL-Cluster untuk menyediakan klaster SQL 2-node dengan cepat [/ caption]

Menyebarkan A SQL Server Failover Cluster Instance Menggunakan Portal Azure

Sementara template penyebaran Azure otomatis adalah cara cepat dan mudah untuk mendapatkan 2-node SQL Server FCI dan berjalan dengan cepat, ada beberapa batasan. Untuk satu, ini menggunakan 180 Hari evaluasi versi SQL Server, sehingga Anda tidak dapat menggunakannya dalam produksi kecuali Anda meng-upgrade lisensi eval SQL. Juga, ia membangun domain AD yang sama sekali baru jadi jika Anda ingin berintegrasi dengan domain yang ada, Anda harus membuatnya secara manual. Untuk membangun 2-node SQL Server Failover Cluster Instance di Azure, kita akan berasumsi Anda memiliki Virtual Network dasar berdasarkan Azure Resource Manager (bukan Azure Classic) dan Anda memiliki setidaknya satu mesin virtual dan berjalan dan dikonfigurasi sebagai Kontroler Domain. Setelah Anda memiliki Jaringan Virtual dan Domain yang dikonfigurasi, Anda akan menyediakan dua mesin virtual baru yang akan bertindak sebagai dua node dalam kelompok kami. Lingkungan kita akan terlihat seperti ini: DC1 – Pengontrol Domain dan File Share Witness SQL1 dan SQL2 – Dua node dari SQL Server Cluster kami

Penyediaan Cluster Nodes (SQL1 dan SQL2)

Dengan menggunakan Azure Portal, kami akan menyediakan SQL1 dan SQL2 dengan cara yang sama. Ada banyak pilihan untuk dipilih termasuk ukuran instan, opsi penyimpanan, dll. Panduan ini tidak dimaksudkan sebagai panduan lengkap untuk menerapkan SQL Server di Azure karena ada beberapa sumber daya yang sangat bagus di luar sana dan lebih banyak diterbitkan setiap hari. Namun, ada beberapa hal penting yang perlu diingat saat membuat instance Anda, terutama di lingkungan yang padat. Ketersediaan Set – Penting bahwa baik SQL1, SQL2 DAN DC1 berada dalam set ketersediaan yang sama. Dengan menempatkan mereka dalam Set Ketersediaan yang sama kami memastikan bahwa setiap node cluster dan file berbagi saksi berada di Domain Fault dan Update Domain yang berbeda. Ini membantu menjamin bahwa selama pemeliharaan yang direncanakan dan pemeliharaan yang tidak terencana, klaster akan terus dapat mempertahankan kuorum dan menghindari downtime. Gambar 3 – Pastikan untuk menambahkan kedua node cluster dan file berbagi saksi ke Set Ketersediaan yang sama [/ caption]

Alamat IP Statis

Setelah setiap VM disediakan, Anda akan ingin masuk ke pengaturan dan mengubah pengaturan sehingga alamat IP adalah Statis. Kami tidak ingin alamat IP dari node cluster kami berubah. Gambar 4 – Pastikan setiap node cluster menggunakan IP statis [/ caption]

Penyimpanan

Sejauh menyangkut Storage, Anda akan ingin berkonsultasi Praktik terbaik kinerja untuk SQL Server di Azure Virtual Machines. Bagaimanapun, Anda akan minimal perlu menambahkan setidaknya satu disk tambahan ke masing-masing node cluster Anda. DataKeeper dapat menggunakan Disk Dasar, Penyimpanan Premium, atau bahkan Storage Pools yang terdiri dari beberapa disk di kolam penyimpanan. Pastikan untuk menambahkan jumlah penyimpanan yang sama ke setiap node cluster dan konfigurasikan secara identik. Gambar 5 – pastikan untuk menambahkan penyimpanan tambahan ke setiap node cluster [/ caption]

Buat Cluster

Dengan asumsi kedua node cluster (SQL1 dan SQL2) telah ditetapkan seperti yang dijelaskan di atas dan ditambahkan ke domain Anda yang ada, kami siap untuk membuat cluster. Sebelum kami membuat gugus, ada beberapa Fitur yang harus diaktifkan. Fitur-fitur ini. Net Framework 3.5 dan Failover Clustering. Fitur-fitur ini harus diaktifkan pada kedua node cluster. Gambar 6 – mengaktifkan fitur .Net Framework 3.5 dan Failover Clustering pada kedua node cluster [/ caption] Setelah fitur-fitur tersebut diaktifkan, Anda siap untuk membangun kluster Anda. Sebagian besar langkah yang akan saya tunjukkan dapat dilakukan melalui PowerShell dan GUI. Namun, saya akan merekomendasikan bahwa untuk langkah pertama ini Anda menggunakan PowerShell untuk membuat kluster Anda. Jika Anda memilih untuk menggunakan GUI Manajer Failover Cluster untuk membuat gugus, Anda akan menemukan bahwa Anda berakhir dengan gugus yang mengeluarkan alamat IP duplikat. Tanpa masuk ke detail besar, apa yang akan Anda temukan adalah bahwa Azure VM harus menggunakan DHCP. Dengan menetapkan "Static IP" ketika kita membuat VM di portal Azure, yang kita lakukan hanyalah membuat semacam reservasi DHCP. Ini bukan reservasi DHCP karena reservasi DHCP yang benar akan menghapus alamat IP dari kumpulan DHCP. Sebaliknya, ini menentukan IP Statis di portal Azure hanya berarti bahwa jika alamat IP tersebut masih tersedia ketika VM memintanya, Azure akan mengeluarkan IP itu padanya. Namun, jika VM Anda offline dan host lain datang online di subnet yang sama, maka akan dikeluarkan alamat IP yang sama. Ada efek samping yang aneh dengan cara Azure mengimplementasikan DHCP. Saat membuat kluster dengan Windows Server Failover Cluster GUI ketika host menggunakan DHCP (yang harus), tidak ada opsi untuk menentukan alamat IP kluster. Alih-alih bergantung pada DHCP untuk mendapatkan alamat. Yang aneh adalah, DHCP akan mengeluarkan alamat IP duplikat, biasanya alamat IP yang sama dengan tuan rumah yang meminta alamat IP baru. Cluster biasanya akan selesai, tetapi Anda mungkin memiliki beberapa kesalahan aneh dan Anda mungkin perlu menjalankan Windows Server Failover Cluster GUI dari node yang berbeda untuk membuatnya berjalan. Setelah Anda mendapatkannya untuk menjalankan Anda akan ingin mengubah alamat IP klaster ke alamat yang saat ini tidak digunakan di jaringan. Anda dapat menghindari kekacauan itu hanya dengan membuat gugus melalui Powershell dan menentukan alamat IP klaster sebagai bagian dari perintah PowerShell untuk membuat kluster. Anda dapat membuat kluster menggunakan perintah New-Cluster sebagai berikut:

Cluster Baru -Name cluster1 -Node sql1, sql2 -StaticAddress 10.0.0.101 -NoStorage

Setelah pembuatan klaster selesai, Anda juga akan ingin menjalankan validasi klaster dengan menjalankan perintah berikut:

Uji-Cluster

Gambar 7 – Output dari pembuatan cluster dan perintah validasi klaster [/ caption]

Buat File Share Witness

Karena tidak ada penyimpanan bersama, Anda harus membuat saksi berbagi file di server lain dalam Kumpulan Ketersediaan yang sama dengan dua node cluster. Dengan menempatkannya dalam ketersediaan yang sama, Anda dapat yakin bahwa Anda hanya kehilangan satu suara dari kuorum Anda pada waktu tertentu. Jika Anda tidak yakin cara membuat File Share Witness, Anda dapat meninjau artikel ini http://www.howtonetworking.com/server/cluster12.htm. Dalam demo saya, saya meletakkan file berbagi saksi di pengontrol domain. Saya telah menerbitkan penjelasan lengkap tentang kuorum klaster di https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum- in-windows-server-2012-r2 / In

Instal DataKeeper

Setelah cluster dibuat, saatnya untuk menginstal DataKeeper. Penting untuk menginstal DataKeeper setelah cluster awal dibuat sehingga jenis sumber daya cluster khusus dapat didaftarkan dengan klaster. Jika Anda menginstal DataKeeper sebelum cluster dibuat, Anda hanya perlu menjalankan instalasi lagi dan melakukan instalasi perbaikan. Gambar 8 – Instal DataKeeper setelah cluster dibuat [/ caption] Selama instalasi, Anda dapat mengambil semua opsi default.  Akun layanan yang Anda gunakan harus merupakan akun domain dan berada di grup administrator lokal pada setiap node dalam gugus. Gambar 9 – akun layanan harus berupa akun domain yang ada di grup Admin Lokal pada setiap node [/ caption] Setelah DataKeeper dipasang dan dilisensikan setiap node Anda perlu reboot server.

Buat Sumber Daya Volume DataKeeper

Untuk membuat DataKeeper Volume Resource Anda harus memulai UI DataKeeper dan terhubung ke kedua server. Hubungkan ke SQL1 Hubungkan ke SQL2 Setelah Anda terhubung ke setiap server, Anda siap untuk membuat Volume DataKeeper Anda. Klik kanan pada Jobs dan pilih "Buat Pekerjaan" Berikan pekerjaan nama dan deskripsi. Pilih server sumber Anda, IP dan volume. Alamat IP adalah apakah lalu lintas replikasi akan bepergian. Pilih server target Anda. Pilih opsi Anda. Untuk tujuan kami di mana kedua VM berada di wilayah geografis yang sama, kami akan memilih replikasi yang sinkron. Untuk replikasi jarak yang lebih jauh, Anda akan ingin menggunakan asynchronous dan mengaktifkan beberapa kompresi. Dengan mengklik ya pada pop-up terakhir, Anda akan mendaftarkan Sumber Daya Volume DataKeeper Baru dalam Penyimpanan Tersedia dalam Failover Clustering. Anda akan melihat Sumber Daya Volume DataKeeper baru dalam Penyimpanan Tersedia.  

Instal Simpul Cluster Pertama

Anda sekarang siap untuk menginstal node pertama Anda. Instalasi klaster akan berjalan seperti kluster SQL lain yang pernah Anda bangun. Saya belum menyalin setiap screen shot, hanya beberapa untuk memandu Anda sepanjang jalan. Anda melihat bahwa Sumber Daya Volume DataKeeper diakui sebagai sumber daya disk yang tersedia, sama seperti jika disk dibagi. Catat alamat IP yang Anda pilih di sini. Itu harus alamat IP unik di jaringan Anda. Kami akan menggunakan alamat IP yang sama nanti ketika kami membuat Penyeimbang Beban Internal kami.

Tambahkan Simpul Kedua

Setelah node pertama berhasil di-install, Anda akan memulai instalasi pada node kedua menggunakan opsi “Add node to a SQL Server failover cluster”. Sekali lagi, instalasinya cukup lurus ke depan, cukup gunakan praktik terbaik standar seperti halnya instalasi klaster SQL lainnya.

Buat Penyeimbang Beban Internal

Di sinilah tempat failover clustering di Azure berbeda dari infrastruktur tradisional. Tumpukan jaringan Azure tidak mendukung ARPS serampangan, sehingga klien tidak dapat terhubung langsung ke alamat IP klaster. Sebaliknya, klien terhubung ke load balancing internal dan dialihkan ke node cluster aktif. Yang perlu kita lakukan adalah membuat penyeimbang muatan internal. Ini semua bisa dilakukan melalui Portal Azure seperti yang ditunjukkan di bawah ini. Pertama, buat Penyeimbang Beban baru Anda dapat menggunakan Penyeimbang Beban Publik jika klien Anda terhubung melalui internet publik. Tetapi dengan asumsi klien Anda berada di vNet yang sama, kami akan membuat Penyeimbang Beban Internal. Hal penting yang perlu diperhatikan di sini adalah bahwa Jaringan Virtual sama dengan jaringan di mana node cluster Anda berada. Juga, alamat IP Pribadi yang Anda tentukan akan PERSIS sama dengan alamat yang Anda gunakan untuk membuat Sumber Daya Cluster SQL. Setelah Internal Load Balancer (ILB) dibuat, Anda harus mengeditnya. Hal pertama yang akan kita lakukan adalah menambahkan kumpulan backend. Melalui proses ini Anda akan memilih Set Ketersediaan di mana Anda SQL Cluster VMs berada. Namun, ketika Anda memilih VMs yang sebenarnya untuk ditambahkan ke Backend Pool, pastikan Anda tidak memilih file Anda berbagi saksi. Kami tidak ingin mengarahkan lalu lintas SQL ke saksi berbagi file Anda. Hal berikutnya yang akan kita lakukan adalah menambahkan Probe. Probe yang kami tambahkan akan memeriksa Port 59999. Probe ini menentukan node mana yang aktif di kluster kami. Dan akhirnya, kita membutuhkan aturan load balancing untuk mengarahkan kembali trafik SQL Server. Dalam contoh kami, kami menggunakan Standar Instance dari SQL yang menggunakan port 1433. Anda mungkin juga ingin menambahkan aturan untuk 1434 atau yang lainnya tergantung pada persyaratan aplikasi Anda. Hal yang penting untuk diperhatikan dalam screen shot di bawah ini adalah Direct Server Return Enabled. Pastikan Anda melakukan perubahan itu.

Perbaiki Sumber Daya IP Server SQL

Satu langkah terakhir untuk Menyebarkan SQL Server Failover Cluster di Azure Resource Manager. Jalankan skrip PowerShell berikut di salah satu simpul klaster Anda. Ini akan memungkinkan Cluster IP Address untuk menanggapi probe ILB dan memastikan bahwa tidak ada konflik alamat IP antara Cluster IP Address dan ILB. Mohon dicatat; Anda perlu mengedit skrip ini agar sesuai dengan lingkungan Anda. Subnet mask diatur ke 255.255.255.255, ini bukan kesalahan, biarkan saja apa adanya. Ini membuat rute khusus host untuk menghindari konflik alamat IP dengan ILB.

# Definisikan variabel
$ ClusterNetworkName = “” 
# nama jaringan klaster 
(Gunakan Get-ClusterNetwork di Windows Server 2012 yang lebih tinggi untuk menemukan namanya)
$ IPResourceName = “” 
# Nama sumber alamat IP 
$ ILBIP = “” 
# Alamat IP Penyeimbang Beban Internal (ILB)
Import-Module FailoverClusters
# Jika Anda menggunakan Windows Server 2012 atau lebih tinggi:
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Beberapa @ {Alamat = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255";
Jaringan = $ ClusterNetworkName; EnableDhcp = 0}
# Jika Anda menggunakan Windows Server 2008 R2, gunakan ini: 
#cluster res $ IPResourceName / priv diaktifkanhcp = 0 alamat = $ ILBIP probeport = 59999  
subnetmask = 255.255.255.255

Kesimpulan

Anda sekarang harus memiliki SQL Server Failover Cluster Instance yang berfungsi. Menghadapi masalah untuk Menyebarkan SQL Server Failover Cluster Di Azure Resource Manager? Hubungi saya di Twitter @daveberm dan saya akan senang membantu. Jika Anda membutuhkan kunci evaluasi DataKeeper, isi formulir di http://us.sios.com/clustersyourway/cta/14-day-trial, SIOS akan mengirimkan kunci evaluasi yang dikirimkan kepada Anda.

SQL Server di Linux Fitur dan Pertimbangan Ketersediaan Tinggi

SIOS akan berbicara di acara Microsoft SQLSaturday

Pembicara Jason Aw, Pengembangan Bisnis Strategis, SIOS Technology Corp, akan berbagi dalam sesi satu jam tentang SQL Server pada Fitur dan Pertimbangan Ketersediaan Linux.

Dengan SQL Server di Linux, Microsoft membawa mesin database relasional inti SQL Server ke ekosistem Linux perusahaan yang sedang berkembang. Ketersediaan Tinggi dan Pemulihan Bencana (HADR) adalah aspek dari SQL Server yang sangat penting dan dalam sesi ini kami membahas fitur, batasan dan opsi untuk Ketersediaan Tinggi dan bagaimana pengelompokan SANless dapat memastikan fungsionalitas, ketersediaan, dan keandalan yang tepat untuk SQL Server di Linux, on-premise dan cloud Azure.

Jason adalah pemimpin TI yang bergairah dengan lebih dari 20 tahun pengalaman dalam teknologi, infrastruktur, lingkungan cloud terutama dengan ketersediaan tinggi dan solusi pemulihan bencana untuk berbagai arsitektur termasuk aplikasi database SQL. Untuk informasi lebih lanjut tentang SIOS, silakan hubungi di sini.

Lacak: Lacak 3

Level: Intermediate

Anda diundang untuk bergabung dengan kami di SQLSaturday

SQLSaturday adalah acara pelatihan gratis bagi para profesional Platform Data Microsoft dan mereka yang ingin belajar tentang SQL Server, Business Intelligence, dan Analytics.

Acara ini akan diadakan pada 18 Agustus 2018 di Microsoft Singapore Operations Pte Ltd, # 22-01 One Marina Boulevard, Singapura, Singapura, 018989, Singapura

DAFTAR SEKARANG

Tentang Acara

Selamat datang di SQLSaturday

Kami bangga menjadi tuan rumah SQLSaturday untuk tahun ketiga berturut-turut di Singapura. SQLSaturday adalah acara pelatihan untuk SQL Server dan profesional data yang ingin belajar bagaimana meningkatkan karir mereka ke tingkat berikutnya.

Masuk ke acara ini gratis, semua biaya ditanggung oleh donasi dan sponsor. Silakan mendaftar segera karena tempat duduk terbatas, dan beri tahu teman dan kolega tentang acara tersebut.

Ini adalah kesempatan bagus untuk belajar dari Tim Produk Microsoft, Microsoft MVP, penulis SQL Server, dan profesional yang telah melalui dan dapat berhubungan dengan rintangan yang Anda hadapi dari hari ke hari. Acara pelatihan satu hari ini tidak seperti yang lain menyediakan makanan gratis, pelatihan, jaringan, dan juga memberikan kesempatan untuk memenangkan beberapa hadiah!

Tanggal & Waktu: Sabtu, 18 Agustus 2018 – 08.30 – 17.30

Gratis

Tempat: # 21-01 Satu Marina Boulevard, Singapura – 018989

Ubah Internet Explorer 11 Dari Bing ke Google

Mengubah Penyedia Pencarian Default Di Internet Explorer 11 Dari Bing ke Google # IE11 #GOOGLE #BING

Bagi Anda yang masih menggunakan IE 11 dari waktu ke waktu, Anda mungkin telah memperhatikan bahwa dengan memperbarui baru-baru ini penyedia pencarian default Anda mungkin telah berubah menjadi Bing. Baca terus jika Anda ingin menemukan cara mengubah Internet Explorer 11 Dari Bing ke Google. Microsoft telah membuat peningkatan keamanan. Ia berharap untuk menghentikan peranti lunak jahat membajak peramban dengan mengubah mesin telusur default dan beranda. Saya seorang ayah dari dua remaja "gamer" yang selalu berada di ambang mengunduh malware terbaru. Jadi sementara saya menghargai keamanan tambahan, ada sedikit kekhawatiran. Salah satu sisi "manfaat" dari pembaruan keamanan ini adalah bahwa penyedia pencarian default sekarang adalah Bing. Mengalihkannya kembali ke Google tidak semudah 1-2-3. Microsoft memposting langkah-langkah tentang cara Mengubah Internet Explorer 11 Dari Bing Ke Google dalam artikel mereka di sini: http://windows.microsoft.com/en-us/windows-10/internet-explorer-11-settings-protection Jangan ingat saya.  Saya suka produk Microsoft. Tapi sayangnya, Bing tidak ramah untuk jenis pencarian yang saya lakukan yang umumnya mencari beberapa konten teknis yang sangat spesifik. Saya pikir Bing mungkin ramah konsumen. Namun, Google memenangkan perang mesin pencari dalam memberi saya jawaban

Ubah Internet Explorer 11 Dari Bing ke Google

Untuk Mengubah Internet Explorer 11 Dari Bing Ke Google, ikuti langkah-langkah di artikel ini. Cuplikan layar di bawah ini menunjukkan langkah-langkahnya.